Zitat von
brechi:
Also das Suspenden/Resumen sollte eigentlich im theoretischem kein Problem darstellen.
In der Theorie gibts da sogar noch mehr Probleme. Timeouts laufen auch weiter während der Prozess suspended ist. Je nach Timeout der getriggert wird, gibts da durchaus lustige Effekte.
Zitat von
brechi:
Man darf halt auch nru die Threads Resumen die wirklich suspended waren (siehe Counter).
Wieso? Wenn ich alle Thread suspende (-> alle Suspend Counter incrementiere), darf ich danach ja auch wieder alle resumen (-> alle Suspend Counter decrementieren).
Zitat von
brechi:
Wenn die Reihenfolge vom Resume wirklich Auswirkungen haben sollte, dann ist das Programm ebene nicht Threadsafe programmiert.
Oder aber man triggert irgendwelche Timeouts, die bei Multithreaded Applications ja durchaus häufiger mal zu finden sind.
Zitat von
brechi:
Und meiner Meinung nach sollte auch ein Hauptthread existieren, ohne den kein anderer Thread laufen würde. Wenn der Abschossen wird, dann beendet sich das komplette Programm. Von daher sollte dieser zu letzt Suspended und zuerst Resumed werden.
Es ist zwar so, daß ohne den ersten Thread alle anderen Threads nicht laufen würden, allerdings wird ein Prozess von Windows erst dann beendet, wenn alle Threads beendet wurden. Für Windows gibts zw. den Threads letztlich keinen Unterschied. Von einem Main Thread zu sprechen ist daher höchst irreführend.
Als kleine Demonstration:
Delphi-Quellcode:
program ThreadDemonstration;
{$APPTYPE CONSOLE}
uses
windows, sysutils;
function ThreadProcedure(NotUsed : pointer) : Integer;
stdcall;
begin
writeln('
Thread aktiv - ID: ', GetCurrentThreadID, '
- Handle: ', GetCurrentThread);
Sleep(INFINITE);
Result := 0;
end;
var
ThreadID : dword;
begin
CloseHandle(CreateThread(
nil, 0, @ThreadProcedure,
nil, 0, ThreadID));
TerminateThread(GetCurrentThread, 0);
// Unschön, muss aber leider sein, weil beim Verlassen des Code Blocks ansonsten ein explizites ExitProcess aufgerufen wird
end.