Anwendung schließen obwohl noch Threads "an" sind?
-
[quote="cd9000Ich hoffe du meinst damit nicht TerminateThread().[/quote]
Neee, nur: Terminate(); //Ist ne BCB- Funktion des Thread- Objektes!
PS: Das mach ich NICHT mit dem Haupt- Thread!
-
flenders schrieb:
Sorry, aber die Logik verstehe ich jetzt nicht so ganz
Bei einen "normalen" Single-Thread Programm läuft der Thread doch ganz normal aus
Und wie sollte man in diesem Thread auf sich selbst warten
Eben, flenders!
Und nun schau Dir nochmal das hier an:
DerAltenburger schrieb:
Beim BCB sollten alle Threads terminiert werden, bevor das Programm stoppt.
..."alle" Threads? Hmm?
-
"Alle" Threads, die neben dem Hauptthread gestartet wurden, falls diese nicht selbst terminieren - beim BCB geht das auch.
-
Ich hab das Ganze mal mitverfolgt. Wenn ich richtig orientiert bin, dann hat doch jeder Prozess seinen eigenen Prozessraum, in dem dann auch die "Unterthreads" mitlaufen, die von dem "Hauptthread" gestartet wurden. Folglich, wenn ich den Prozess beende, wird der Prozessraum gelöscht, oder freigeben, und damit auch alle enthaltenen anderen Threads.
Was aber für mich nun noch nicht so ganz zu Tage getreten ist, ist die Frage: Macht es nun Sinn alle Unterthreads zu beenden bevor man ein Programm beendet oder reicht es vollkommen aus, wenn man das nur bei kritischen Threads macht, die z.B. Schreibop's auf die Festplatte machen?
Allerdings ist es doch unsauber, wenn man es nicht bei allen Threads macht. Beim BCB springt dann der CodeGuard an und schreibt dann die offenen Ressourcen in eine Textdatei.Also was ist ratsam?
-
Ich würde sagen, es ist das Sauberste, wenn du dafür sorgst, dass alle Threads ordentlich "auslaufen"
-
DerAltenburger schrieb:
Neee, nur: Terminate(); //Ist ne BCB- Funktion des Thread- Objektes!
Was wird Terminate() schon anderes machen als TerminateThread aufzurufen?
Hast du keine BCB-Doku?
Ich habe keinen BCB, aber ich vermute sehr stark dass in der Doku steht, man darf Terminate nur in absoluten Ausnahme-Fällen nutzen und nie standardmäßig um überflüssige Threads abzuschießen.
Wie flender eben gesagt hat, es ist viel besser die Threads auslaufen zu lassen. Du kannst ja eine Variable (Event, Mutex, was auch immer) verwenden. Diese Variable wird regelmäßig von den Threads gecheckt; wenn sie gesetzt ist beenden sich die Threads. Gesetzt wird sie, wenn der Hauptthread aufhören will.
-
cd9000 schrieb:
Du kannst ja eine Variable (Event, Mutex, was auch immer) verwenden.
Da reicht auch ein ganz normaler kleiner BOOL-Zeiger, der Haupt- und Unterthread bekannt ist.
-
Nur dass man dann darauf im Haupt-Thread nicht so effizient warten kann
-
flenders schrieb:
Nur dass man dann darauf im Haupt-Thread nicht so effizient warten kann
Das nicht, aber _beginthreadex liefert einen Handle auf das ThreadObjekt zurück, auf das man dann mit WaitForSingleObject/WaitForMultipleObjects warten kann...
Also z. B. so:
iMaxThreads = 10; HANDLE hThread[10]; BOOL bThreadLaeuft[10]; . . . case WM_CLOSE: for(i=0; i < iMaxThreads; i++) { if(bThreadLaeuft[i]) { WaitForSingleObject(hThread[i], INFINITE); CloseHandle(hThread[i]); } } return 0;
-
Auch wahr
-
cd9000 schrieb:
DerAltenburger schrieb:
Neee, nur: Terminate(); //Ist ne BCB- Funktion des Thread- Objektes!
Was wird Terminate() schon anderes machen als TerminateThread aufzurufen?
Terminate() im BCB setzt eine (innere) Variable Terminated auf true. Die sorgt i.a. fuer das auslaufen des Thread! (Falls der ordentlich programmiert ist!)
-
DerAltenburger schrieb:
Terminate() im BCB setzt eine (innere) Variable Terminated auf true. Die sorgt i.a. fuer das auslaufen des Thread! (Falls der ordentlich programmiert ist!)
Was heißt "ordentlich programmiert"?
-
cd9000 schrieb:
Was heißt "ordentlich programmiert"?
Der Thread sollte die Variable Terminated testen und, falls die true ist, auslaufen.
Beim BCB kann sich der Thread dann auch aus Speicher freigeben (FreeOnTerminate)