MrY schrieb:
Deinen Einwand verstehe ich nicht ganz. Die noch nicht angekommenen Messages (Also pending IOs) gehen verloren, wenn der Thread abgemurkst wird?
Die gehen auch verloren, wenn der Thread sich "ganz normal" brav selbst beendet, indem z.B. die Thread-Funktion "return;" macht.
So. Hat einige Zeit gedauert bis ich die Stelle in der MSDN wiedergefunden habe, wo das beschrieben steht. Aber hier ist sie (Doku zu ExitThread): http://msdn.microsoft.com/en-us/library/ms682659(VS.85).aspx
MSDN schrieb:
When this function is called (either explicitly or by returning from a thread procedure), the current thread's stack is deallocated, all pending I/O initiated by the thread is canceled, and the thread terminates. (...)
BTW: Wenn man mit asynchronen IOs arbeitet, den Thread der diese startet selbst kontrolliert, und vermeiden möchte dass man zu früh die Thread-Funktion verlässt, kann man dazu GetThreadIOPendingFlag verwenden. Ein einfacher Polling Loop (mit nem Sleep drinnen) reicht hier wohl meistens.
Außerdem kann man Threads nicht immer geordnet herunterfahren! Sei es ein Blocking-Call oder ein Prozess-Crash...
Dann muss man es eben bleiben lassen TerminateThread ist auf jeden Fall keine Lösung. Wenn man warten kann, dann warten, sonst halt TerminateProcess.
Nochwas: ab Vista oder Windows 7 (weiss ich nimmer, und bin grad zu faul noch weiter zu suchen) werden nichtmehr alle IOs gecancelt, sondern nurmehr die, die nicht einem IO Completion Port zugeordnet sind. Da hat wohl jemand mitgedacht (spät, aber besser als nie).
