Der Martin: Win32-API: CreateThread(), Threads koordinieren

Beitrag lesen

Hallo Kameraden,

gerade komme ich mal wieder in den Genuss, mich in meinem alten Spezialgebiet Softwareentwicklung zu bewegen. Und bin auf ein Phänomen mit einer win32-Anwendung gestoßen.

Um eine zusätzliche Aktion nebenläufig zu realisieren (Kommunikation über eine Sellerie-Schnittstelle), ohne das Hauptprogramm zu beeinflussen, habe ich diese zusätzliche Aktion in einen eigenen Thread verlagert - also ein paar sequentielle Aufrufe von WriteFile() und ReadFile() auf ein Comm-Handle. Nun habe ich beim Testen festgestellt, dass beim Schließen des Programms hin und wieder zwar das Programmfenster verschwindet, der eigentliche Prozess aber als Zombie übrigbleibt. Im Taskmanager ist er dann noch zu sehen.

Aufgefallen ist das, weil das Programm sich dann beim Neustart beklagt, die COM-Schnittstelle könne nicht geöffnet werden, weil sie noch von einem anderen Prozess belegt ist. Das Debugging gestaltet sich ein bissl unbequem, da der zusätzliche Thread in einer DLL steckt, die "on demand" geladen wird.

Ist es in win32 tatsächlich Pflicht, das Beenden aller Threads zu überwachen und abzuwarten, bevor man das Hauptprogramm enden lässt? Ich hätte gedacht, wenn der Thread noch ein paar Sekunden läuft, dann verzögert sich halt auch das Beenden des Hauptprozesses. Aber anscheinend ist das nicht so.

Hat da jemand Erfahrungen?

Live long and pros healthy,
 Martin

--
Home is where my beer is.