Handling:

1. eigenen Worker bauen mit = class(TWorker)
2. Worker Liste instanzieren
3. Worker instanzieren
4. Worker in die Liste legen.
5. der Rest geht fast von selbst...
6. Das Wegwerfen der Liste hat ein koordiniertes Aufräumen der Threads zur Folge. (selbstverständlich sollte im Thread, je nach Komplexität, mehrfach auf Terminated geprüft werden. Sonst läuft der Thread logischerweise bis zum Ende durch )

PS. Ich bin grad am Ausbauen der Visuellen Rückmeldungen. Mal schauen.

Zitat:

Und warum das "of object"? Ich hasse das, warum soll ich keine anonymen Methoden übergeben können? Mach doch bitte "reference to procedure(..)".

..erklär mal genauer warum du das nicht magst. Oder anders: Was ist daran falsch?

Ok vielleicht verstehe ich es nicht...

Aber der Teil, der die Arbeit auf die Worker verteilt fehlt...
Was Du angefügt hast ist doch nicht anderes wie ein Threadrumpf und eine Liste die Threads verwaltet.

Wo ist der Sync, der Wait, der Terminate usw.

Hallo...

Zitat:

Wo ist der Sync, der Wait, der Terminate usw.

...alles im Threadrumpf bzw der Liste.

zusammenfalten · markieren

Delphi-Quellcode:

const
  PM_Finish_Thread = WM_USER + 1;

procedure TdWorkerList<T>.Remove(aThread: TThread);
begin
  aThread.Terminate;
  aThread.WaitFor;
  aThread.Free;
  inherited Remove(aThread);
end;

procedure TdWorkerList<T>.TreadFinished(var Msg: TMessage);
begin
   if (not FDestroying) and (Msg.Msg = PM_Finish_Thread) then
   begin
     Remove(TThread(Msg.wParam));
   end;
end;

Der Thread selbst schickt eine Message an die Liste das er fertig ist.

markieren

Delphi-Quellcode:

procedure TWorker.DoOnTerminate(Sender: TObject);
begin
  PostMessage(FListHandle, PM_Finish_Thread, wParam(Self), 0);
end;

Letztendlich ist das alles unerheblich. Der Thread ist definitiv fertig und freigegeben. Das schließt dieses Konstukt aus. Ich hatte gehofft das ihr andere Ideen habt.

Also sollen das keine WorkerThread für eine Aufgabe sein, sondern Du Assignest Du nur in eine Liste um alle Terminieren zu können?

Nur so am Rande bemerkt, wer diesen Block

markieren

Delphi-Quellcode:

TThread.Terminate;
TThread.WaitFor;
TThread.Free;

so aufruft, der hat sich TThread.Destroy noch nicht angesehen, denn dann würde man dieses Triumvirat ersetzen durch TThread.Free;

Hallo Maverik,

wie du schon sagtest. Das ist der Rumpf mit den Events und der "Habe fertig" Logik. Auf TWorker setzen dann die eigentlichen Worker auf. Die Liste dient nur der Verwaltung der Threads (jeder Thread trägt sich quasi selbst aus der Liste aus).
Ich hatte das eigentlich nur mit angeführt um die Zusammenhänge besser zu erklären. Das Konstrukt funktioniert in einem anderen Projet ganz normal. Auch die IDE ist nach der Beendigung des anderen Projektes sofort wieder da. Nur in diesem ist die Verzögerung beim Beenden vorhanden.
Meine erstellten Threads tragen Namen. Die nach dem Beenden erzeugten Threads, und das Warten auf deren Beendigung, haben nur Nummern. Mit welchem Werkzeug kann ich herausfinden wer die Threads erstellt?

PS: Auch mit normal TThread und FreeOnTerminate ist beim Beenden die Verzögerung.

Zitat:

so aufruft, der hat sich TThread.Destroy noch nicht angesehen, denn dann würde man dieses Triumvirat ersetzen durch TThread.Free;

hast du es mal nicht nur mit TThread probiert sondern mit Ableitungen und erstellten Interfaces im Constructor der Ableitung? Vom reinen Quelltext (TThread.Destroy) gebe ich dir Recht. Nur hagelt es in diesem Falle Fehlermeldungen bevor der Destructor von TThread aufgerufen wird. (und damit das Terminate + WaitFor). Meine Fehler haben mit der Datenbankverbindung zu tun. Mein DB Framework, welches als Interface im Constructor des Workers erstellt wird, ist bereits über die Referenzzählung abgräumt, da die Destructoren durchlaufen werden.
In diesem Falle ist das Terminate und WaitFor vor dem Free notwendig und richtig. Oder hast du dafür auch eine Patentlösung...

Eine Patentlösung habe ich nicht. Ich mache es mir da einfach und implementiere es einfach nur richtig und schon funktioniert es:

zusammenfalten · markieren

Delphi-Quellcode:

TFooThread = class( TThread )
private
  FChair : TChair; // da setzt sich der Thread drauf
protected
  procedure Execute; override;
public
  constructor Create;
  destructor Destory; override;
end;

procedure TFooThread.Execute;
begin
  while not Terminated do
    FChair.SitDown(); // exessive Verwendung der TChair-Instanz
end;

constructor TFooThread.Create;
begin
  FChair := TChair.Create; // bevor irgendwas losläuft, erzeugen wir die TChair-Instanz
  inherited Create( False ); // der Thread selber wird erzeugt
end;

destructor TFooThread.Destroy;
begin
  // Der Thread kann jetzt noch aktiv sein,
  // darum dürfen wir ihm jetzt nicht den Stuhl unter dem Hintern wegziehen
  inherited;
  // Jetzt ist der Thread gesichert beendet
  // und nun kann die TChair-Instanz bedenkenlos aufgeräumt werden
  FChair.Free;
end;

Update...

2 Tage in der falschen Richtung gesucht. Es liegt definitiv nicht an den Threads. Das funktioniert hervorragend. Der bewußte Thread macht eine Datenübernahme aus einer alten Datenbankstruktur in eine neue Struktur. Weil ich noch in der Entwicklung bin wird jeder Step gleich commited (damit ich kontrollieren kann). Später läuft das in einer Transaktion. Dies habe ich nun mal probiert. Dabei stellte sich heraus, das der Firebird mit seinen Commits der mehreren tausend Datensätze nicht hinterherkam. Deshalb beim Beenden die Verzögerung. Wenn man mit dem Beenden lange genug gewartet hat, ging es auch schnell. Wenn das alles in einer Transaktion abgearbeitet wird, braucht halt das Commit länger. Das Beenden geht danach sofort.

Schön das wir darüber geredet haben...