Es empfiehlt sich eher, über JobObjectBasicAccountingInformation und das Struktur-Element ActiveProcesses zu gehen. Bei der Prozess-ID-Liste sind vermutlich auch die terminierten Prozesse enthalten, oder zumindest jene, auf die noch jemand ein
Handle hält.
Beim Warten darauf, dass alle Prozesse beenden werden, wird es kompliziert. Man kann zwar auf einen Job warten, das Objekt wird aber nicht etwa signalisiert, wenn alle Prozesse beendet sind, nein, es wird signalisiert, wenn die gesetzte Job-Zeit-Grenze erreicht ist (eigentlich sind Jobs dazu da, einer Gruppe von Prozessen Grenzen, z.B. für die Ausführungszeit und den Speicherverbrauch, zu geben, also eine Art Sandbox). Warum Microsoft das so eingerichtet hat, ist mir ein Rätsel. Um auf das Ende aller Prozess in einem Job zu warten und gleichzeitig Nachrichten zu verarbeiten, muss ein eigener Thread eingesetzt werden.
Zitat von
Apollonius:
Für einen ereignisgesteuerten Ansatz kann man dem Job einen IO Completion Port zuweisen, welcher eine Nachricht erhält, wenn alle Prozesse beendet sind. Das muss allerdings in einem eigenen Thread geschehen, da es dann nicht möglich ist, auf Fensternachrichten zu reagieren.
Für diese Technik musst du zuerst einen IO Completion Port erstellen (CreateIoCompletionPort). Mit SetInformationJobObject kannst du dann den Port für Benachrichtigungen eintragen. Auf Benachrichtigungen wartest du mit GetQueuedCompletionStatus. Und genau dort liegt das Problem: Es ist weder möglich, auf weitere Objekte zu warten, noch kann man auf Fensternachrichten oder APCs warten (letzteres geht ab Windows Vista mit GetQueuedCompletionStatusEx). Daher solltest du am Anfang deines Programms einen Thread starten, der mit unbegrenztem Timeout auf einen Completion Port wartet. Mit einem beliebigen Mechanismus kann er dem Hauptthread dann die Nachrichten zugänglich machen. Beenden kannst du den Thread, indem du mit PostQueuedCompletionStatus eine eigene Nachricht verschickst, die der Thread erkennt. Daraufhin sollte er sich beenden.