TThreadPool.Default.QueueWorkItem - wie parameter mitgeben

[newbe]

Hallo zusammen!

Ich habe hier folgenden Aufruf

TThreadPool.Default.QueueWorkItem(TestPing); Ich möchte gerne der dem Workerevent, also der Procedure "TestPing" mehrere Parameter mitgeben, habe aber keine Ahnung wie das zu bewerkstelligen ist?
Hat jemand dazu eine passende Idee?

mfg newbe

[himitsu]

Delphi-Quellcode:

S := 123;  // lokale Vaiable oder Parameter der übergeordneten Prozedur
TThreadPool.Default.QueueWorkItem(procedure
  begin
    TestPing(123, S);
  end);

Wichtig, das darf so nicht in einer Schleife aufgerufen werden.
z.B. als AddToPool wegkapseln, oder noch besser, QueueWorkItem erweitern (ableiten oder ClassHelper) und den oberen Code dort rein (TestPing als Parameter TProc<T1,T2> )

[newbe]

Ah Danke himitsu, werde ich mal probieren. Dieses konstrukt TProc<T1,T2> is eine generic oder? Habe damit noch nicht gearbeitet, erinnert mit aber an die Tuple Class von C#. Warum darf das nicht in einer Schleife aufgerufen werden? Hab ich auch nicht vor, nurmal zur Info wäre es interessant.
Und wie definiere ich denn in Delphi den Typ von T1 und T2?

mfg newbe

//edit

Also anscheinend brauch ich da gar nix deklarierern, Der übergabecode funktioniert. habe es jetzt mal so ganz einfach getestet

Delphi-Quellcode:

TThreadPool.Default.QueueWorkItem(procedure
      begin
        TestPing5('123');
      end);

Finde ich aber ehrlich gesagt bescheuert vom Code her. Gib es eine Möglichkeit Testping direkt mit den Parametern aufzurufen? Ziemlich umständlich das ganze. Sollte dann so funktionieren?

Delphi-Quellcode:

procedure AddToPool(ip: String, bla: Integer);
begin

 TThreadPool.Default.QueueWorkItem(procedure
      begin
        TestPing5(ip, bla);
      end);

 end;

KAnn ich mir das Kapseln irgendwie sparen???

[himitsu]

Jupp. Es gibt eine Reihe vordefinierter generischer Typen, welche man benutzen kann.

Delphi-Quellcode:

type
  TArray<T> = array of T;
  TProc<T> = procedure(A: T);
  TProc<T,T2> = procedure(A: T; A2: T2);
  TProc<T,T2,T3> = procedure(A: T; A2: T2; A3: T3);
  ...

Also praktisch ganz einfach so

Delphi-Quellcode:

class procedure TMeinHelper.AddToPool<T,T2>(P: TProc<T,T2>; A: T; A2: T2);  // leider können einfache Funktionen nicht generisch sein
begin
  TThreadPool.Default.QueueWorkItem(procedure
    begin
      P(A, A2);
    end);
end; 

TMeinHelper.AddToPool<string,Integer>(TestPing5, ip, bla);
TMeinHelper.AddToPool<Integer,string>(TelefoniereNachHause, 666, 'Hölle');

Könnte man auch via Class-Helper direkt an den TThreadPool hängen, als überladene Variante von QueueWorkItem.

Ist letztendlich die generische Variante von Nachfolgendem, nur daß man hier eben alle möglichem Prozeduren mit zwei Parametern übergeben kann.
Und TPoolAddProcWithTwoParams muß man auch nicht selber deklarieren, weil es das schon fertig gibt.

Delphi-Quellcode:

type
  TPoolAddProcWithTwoParams = procedure(A: string; A2: Integer);

procedure AddToPool(P: TPoolAddProcWithTwoParams; A: string; A2: Integer);
begin
  TThreadPool.Default.QueueWorkItem(procedure
    begin
      P(A, A2);
    end);
end; 

AddToPool(TestPing5, ip, bla);

Natürlich hätte Emba auch einfach nur mal intelligent sein können und ein/zwei solcher Überladungen von QueueWorkItem direkt in TThreadPool integrieren können.

[Der schöne Günther]

Die Frage mit deinem "Nicht in einer Schleife benutzen" hast du aber noch nicht beantwortet

Das habe ich nämlich auch nicht verstanden.

[newbe]

Das heisst ich komme nicht drumrum mir für jede in den Parameter Abweichende Workermethode eine extra Addpoolwithparams methode zu schreiben bzw ein ensprechenden classhelper zu implementieren? In meinen Augen unnötig und totaler Schwachsinn, wenn nicht irgendeine technische Gegebenheit dies verlangt.
Ich möchte nicht für jede abweichende parameter anzahl und art eine extra Add methode implementieren und dann nochmal alle parameter in dem eigentlichen Workermethodenkopf aufführen müssen.

also sowas in der Art

Delphi-Quellcode:

bla:= TDictionnary.create erzeugen

Dictionary.Add(kvp("ipadresse"), '127.0.0.1')
Dictionary.Add(kvp("Timeout"), 1000)
...usw.                                       //beliebig viele daten hinzufügen

AddMethodwithXParamstoThreadpool(TDictionnary of KeyValuePair (Varbez String, Datentyp dynamic));
begin
   TThreadPool.Default.QueueWorkItem(procedure  
    begin 
      machwas(bla);
    end);
end;

warum nicht einfach so???

  TThreadPool.Default.QueueWorkItem(machwas(bla)); Classhelper gespart + unnötige begin end block gespart? Aber mitdenken ist wohl nicht so angesagt bei den jungs.

[himitsu]

AddPoolWithParams bekommt einen "Zeiger" auf die Prozedur und die Parameter rein und ruft diese Prozedur intern auf.

Bei TThreadPool.Default.QueueWorkItem(machwas(bla)); würde erst machwas ausgeführt und dann dessen Result als Parameter in QueueWorkItem reingegeben.
Siehe ShowMessage(IntToStr(123)); ... S:=IntToStr(123); ShowMessage(S);


Delphi legt solche gesharedten Variablen intern in ein Interface und gibt Jenes an alle, welche mit dieser Variable zu tun haben.
Drum können z.B. auch keine Var-Parameter von der äußeren Prozedur in den Generic reingegeben werden, da diese Variablenkopie eventuell länger lebt, als der Parameter und seine Referenz, also auch nach dem Ende der aufrufenden Prozedur, da Delphi nicht erkennen kann (nicht schlau genug dafür ist), ob die generische Methode bereits vorher beendet ist.

Delphi-Quellcode:

for i := 0 to 10 do
  TThreadPool.Default.QueueWorkItem(procedure
    begin
      if i = 5 then
        Beep;
    end);

Hier haben also Alle die selbe Variable und bevor die Prozedur ausgeführt wird, kann/wird die Variable bestimmt schon einen anderen Wert haben, also Den von einem der nachfolgenden Schleifendurchläufe.
Mit einer Prozedur (z.B. das AddToPool) drumrum, bzw. dazwischen (zwischen Schleife und generischem Aufruf) wird über den Parameter eine Kopie der Variable erstellt und jeder bekommt seine eigene Instanz davon.
Bei globaler Variable gäbe es wieder das selbe Problem.

Delphi-Quellcode:

S := 'Welt';
B := False;
while not B do
  TThread.Synchronize(nil, procedure
    begin
      B := InputQuery('Hallo', 'Du', S);
    end;
if S <> 'Welt' then
  FühreWeltuntergangHerbei;

Bei "syncronen" Aufrufen, also wo der Methodenzeiger nicht gespeichert und/oder in einen anderen Thread übergeben wird, da gibt keine Probleme, aber Delphi geht nunmal immer davon auß, als könnte der Aufruf auch asynchron, bzw. verzögert erfolgen und/oder beendet sein.

[Sir Rufo]

Ich würde es immer trennen und einen generischen Wrapper erstellen, der dann bis zu x Argumenten wrappen kann:

Delphi-Quellcode:

function TWrapper.Wrap<T>( AProc : TProc<T>; Arg: T ): TProc;
begin
  Result := procedure
  begin
    AProc( Arg );
  end;
end;

und dann einfach

Delphi-Quellcode:

var s: string;

TThreadPool.Default.QueueWorkItem( TWrapper.Wrap<string>( procedure ( Arg: string ) begin ... end, s ) );

[newbe]

@Sir Rufo so ähnlich meinte ich es ja mit dem keyValuePair Dictionary, aber seien wir mal ehrlich, von der Eleganz und Simplizität einer einfachen methodenübergabe sind wir immer noch weit entfernt. :/ Aber scheint wohl keine andere Möglichkeit zu geben.

mfg newbe

[newbe]

Delphi-Quellcode:
function TWrapper.Wrap<T>( AProc : TProc<T>; Arg: T ): TProc;
begin
Result := procedure
begin
AProc( Arg );
end;
end;
und dann einfach
markieren Delphi-Quellcode:
var s: string;

TThreadPool.Default.QueueWorkItem( TWrapper.Wrap<string>( procedure ( Arg: string ) begin ... end, s ) );

Sir Rufo,

ich habe Probleme deinen Code zu verstehen, könntest du mir ein paar Fragen beantworten?

1. TWrapper.Wrap<string> Was soll da in <string> drinstehen bspw.?
2. Ich kann mir durchaus vorstellen das, das mit übergebenen Konstantenwerten funktioniert die in die QueeWorkItem-function reingehen, aber was ist z.B
mit Variablen, oder Sets, Arrays usw.?
3. Habe ich noch nicht viel mit generischen Methoden gearbeitet, wäre schön wenn du es etwas "aufdröseln" könntest.

danke schonmal im Voraus,

mfg newbe