TTimer nicht Thread-safe

[himitsu]

Mit TTimer geht es nunmal nicht im Thread, aber natürlich kann man SetTimer auch innerhalb eines Threads benutzen.
* man muß nur ein Message-Windows im Thread erstellen und da drin einen Timer aktivieren
* und man muß im Thread natürlich auch auch die Window-Messages verarbeiten, vor allem WM_TIMER

[hzzm]

Zitat:

Zitat von himitsu (Beitrag 1393206)

Mit TTimer geht es nunmal nicht im Thread

Mein Problem ist momentan eher, dass ich ausserhalb des Threads einen riesigen Timer-gesteuerten Ablauf je nach Thread-Ergebnis an- oder ausschalten muss.
Den kann/moechte ich gar nicht komplett im Thread unterbringen, da dieser Ablauf noch an zig anderen Stellen im Code regulaer verwendet wird.

Ich muesste den Timer ausserhalb eben nur aus dem Thread anstossen.

Darf ich das mit .Queue?

[himitsu]

TThread.Synchronize oder TThread.Queue ... wird beides im Hauptthread ausgeführt.

SendMessage und PostMessage ebenso (wenn das zugehörige Window im Haupthtread erstellt wurde) und PostThreadMessage sowieso.

[Zacherl]

Zitat:

Zitat von CCRDude (Beitrag 1393184)

Sleep in einem Thread ist auch nicht gut. Wenn das System runter fährt, benachrichtigt es Dein Programm, das muss sich in einer kurzen Zeit beenden können, sonst wird es als eingefroren angezeigt.

Das kann man umgehen, indem man statt

Delphi-Quellcode:

Sleep

einfach WaitForSingleObject mit einem Event (bzw. die entsprechende Kapselung

Delphi-Quellcode:

TEvent

) verwendet. Das Event lässt man permanent auf nonsignaled, bis man von Windows die

Delphi-Quellcode:

WM_QUERYENDSESSION

bzw.

Delphi-Quellcode:

WM_ENDSESSION

Nachricht erhält. Sobald man das Event dann aktiviert, arbeiten alle Threads unmittelbar weiter, ohne auf das Timeout zu warten. Im Thread selbst sollte man dann noch die Rückgabe von

Delphi-Quellcode:

WaitForSingleObject

prüfen, und die Bearbeitung entsprechend sofort einstellen, wenn nicht

Delphi-Quellcode:

WAIT_TIMEOUT

zurückgegeben wurde.

[CCRDude]

Zitat:

Zitat von Zacherl (Beitrag 1393211)

Das kann man umgehen, indem man statt

Delphi-Quellcode:

Sleep

einfach WaitForSingleObject mit einem Event (bzw. die entsprechende Kapselung

Delphi-Quellcode:

TEvent

) verwendet. Das Event lässt man permanent auf nonsignaled, bis man von Windows die

Delphi-Quellcode:

WM_QUERYENDSESSION

bzw.

Delphi-Quellcode:

WM_ENDSESSION

Nachricht erhält.

Noch praktischer: ich verwende eine von TThread abgeleitete Basis-Klasse, die dieses Warten als Methode anbietet und das Event im Terminate auslöst. Damit hilft das nicht nur beim Runterfahren Verzögerungen zu vermeiden, sondern auch beim schlichten Beenden des Programmes oder gar nur des Threads.

[Zacherl]

Zitat:

Zitat von CCRDude (Beitrag 1393234)

Zitat:

Zitat von Zacherl (Beitrag 1393211)

Das kann man umgehen, indem man statt

Delphi-Quellcode:

Sleep

einfach WaitForSingleObject mit einem Event (bzw. die entsprechende Kapselung

Delphi-Quellcode:

TEvent

) verwendet. Das Event lässt man permanent auf nonsignaled, bis man von Windows die

Delphi-Quellcode:

WM_QUERYENDSESSION

bzw.

Delphi-Quellcode:

WM_ENDSESSION

Nachricht erhält.

Noch praktischer: ich verwende eine von TThread abgeleitete Basis-Klasse, die dieses Warten als Methode anbietet und das Event im Terminate auslöst. Damit hilft das nicht nur beim Runterfahren Verzögerungen zu vermeiden, sondern auch beim schlichten Beenden des Programmes oder gar nur des Threads.

Ja, genau so hatte ich es damals auch umgesetzt und dafür die

Delphi-Quellcode:

TerminatedSet

Methode überschrieben :thumb: