Ich habe auch nicht gesagt, dass das nicht funktioniert, es gibt aber ein ganz schmales Zeitfenster, wo das nicht funktioniert.
Das doofe daran ist, wenn man es gar nicht gebrauchen kann, dann schlägt das zu (Murphy)
Irgendwie stehe ich hier auf dem Schlauch
Ich prüfe doch direkt nach dem WaitForSingleObject auf Terminated. Und in der überschriebenen Terminate Funktion des Threads setze ich erst Terminated und dann löse ich das Event aus. Aber wie auch immer ..
Folgendes Szenario:
Der Thread holt sich über die LockList die Transfer-Elemente und kopiert diese. Dann gibt er diese LockList wieder frei. Genau zu diesem Zeitpunkt wird der Thread terminiert (FWaitEvent wird gesetzt und der Thread auf Terminated). Jetzt sind aber keine Elemente in der Liste, also setzt der Thread das FWaitEvent zurück und wartet darauf, dass das Event kommt (unendlich).
Der Thread wird also nicht beendet
Dies ist zwar theoretisch aber ich habe bei genau sowas schon die kotzenden Pferde gesehen.
Bis du dann dem Entwickler dediziert beschreiben und vor allem nachweisen kannst, dass da was falsch läuft - gute Nacht Marie
Hier mal mein Vorschlag für den Händler
.. dein Ansatz mit der Queue sieht sehr gut aus
Muss ich mir mal genauer anschauen, ob die TQueue Klasse von Delphi das Verschieben von Einträgen unterstüzt oder mir was eigenes basteln. Wollte dem User die Möglichkeit lassen, die Reihenfolge der Übertragungen zu ändern.
Dafür benötigst du eine sortierte Liste (mit einem Comparer)
TComparer<T>
Die Send-Queue würde ich aber genau so nehmen und die Reihenfolge nur für die wartenden Transfers berücksichtigen.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ea 0a 4c 14 0d b6 3a a4 c1 c5 b9
dc 90 9d f0 e9 de 13 da 60)