Thread-ID?

[Jochen Kalmbach]

Ich kann Dir leider auch in keinster Weise folgen...
Hast Du mein Beispiel probiert? Und welches Verhalten kannst Du da jetzt (nicht) nachvollziehen?
Was das Beispiel macht ist simple: Es wird gestartet, erzeugt einen Thread und beendet sich wieder! Und der Effekt ist, dass der Entry-Thread schon längst beendet ist (also das was Du als Main-Thread bezeichnest) und der zweite Thread noch immer läuft und somit auch der Prozess noch läuft...

Und zur Doku: Die MSDN hat so viele Fehler, da kommt es auf diese Kleinigkeit nicht an...

Und was mein Beispiel macht wiederlegt exact diese Behauptung in der MSDN...
Bei mir liefert mein Beispiel:

Bin im Haupt-Thread...
Bin in Thread 2!
Bin in Thread 2!
Bin in Thread 2!
Bin in Thread 2!
Bin in Thread 2!
Bin in Thread 2!
Bin in Thread 2!
Bin in Thread 2!
(usw.)

Add: Vielleicht hat sich das Verhalten auch seit XP geändert! XP ruft nämlich bei einem "return" aus dem Main-Thread direkt "ExitThread" auf... was dann lt. der Doku ein Terminate verhindert, wenn noch ein anderer Thread läuft...
http://msdn.microsoft.com/library/en-us/dllproc/base/terminating_a_process.asp

[groovemaster]

LOL, jetzt verstehe ich, was du für Schweinereien machst. Nimm mal einen vernünftigen Entry-Point ala main oder WinMain, so wie man halt ein Programm idR beginnt. Dann wirst du sehen, dass du über einen Spezialfall sprichst. Für "normale" Anwendungen gilt das jedenfalls nicht.

Jochen Kalmbach schrieb:

Was das Beispiel macht ist simple: Es wird gestartet, erzeugt einen Thread und beendet sich wieder!

Ja, und bei einer "normalen" Anwendung wird dabei der Prozess und somit alle Threads abgeschossen.

Jochen Kalmbach schrieb:

Und der Effekt ist, dass der Entry-Thread schon längst beendet ist (also das was Du als Main-Thread bezeichnest)

Ich habe nie etwas als "Main-Thread" bezeichnet, sondern sprach von Primärthread. Und so nennt es zumindest die Doku.

Jochen Kalmbach schrieb:

und der zweite Thread noch immer läuft und somit auch der Prozess noch läuft...

Wie gesagt, für "normale" Anwendungen trifft das nicht zu.

Jochen Kalmbach schrieb:

Und zur Doku: Die MSDN hat so viele Fehler, da kommt es auf diese Kleinigkeit nicht an...

Mag sein, dass die Doku Fehler hat. Aber in dem von mir bereits zitierten Punkt ist sie eindeutig und fehlerfrei.

Jochen Kalmbach schrieb:

Und was mein Beispiel macht wiederlegt exact diese Behauptung in der MSDN...

Nein, dein Beispiel belegt lediglich, dass du einen benutzerspezifischen Entry-Point definieren kannst und damit gewisse Festlegungen eines Default Frameworks aushebeln kannst. Glückwunsch!
Dein Hinweis war zwar berechtigt, nur hättest du dazu schreiben sollen, dass dies nicht für "normale" Anwendungen gilt. Dann hätten wir uns die ganze Diskussion sparen können. Wobei ich mir noch nicht mal sicher bin, ob das, was du schreibst implementationsspezifisch ist. Vielleicht erzeugt ein Compiler ja immer ein Framework, was das Standardverhalten sichert, egal ob benutzerspezifischer Entry-Point oder nicht.

Jochen Kalmbach schrieb:

XP ruft nämlich bei einem "return" aus dem Main-Thread direkt "ExitThread" auf...

Sry, auch das kann ich der Doku nicht entnehmen. Vllt. kannst du ja mal die Quelle dazuschreiben.

[Jochen Kalmbach]

groovemaster schrieb:

LOL, jetzt verstehe ich, was du für Schweinereien machst. Nimm mal einen vernünftigen Entry-Point ala main oder WinMain, so wie man halt ein Programm idR beginnt. Dann wirst du sehen, dass du über einen Spezialfall sprichst. Für "normale" Anwendungen gilt das jedenfalls nicht.

Naja... zumindest für Anwendungen welche die MS-CRT verwenden, da diese explizit ExitProcess aufruft

groovemaster schrieb:

Jochen Kalmbach schrieb:

Und zur Doku: Die MSDN hat so viele Fehler, da kommt es auf diese Kleinigkeit nicht an...

Mag sein, dass die Doku Fehler hat. Aber in dem von mir bereits zitierten Punkt ist sie eindeutig und fehlerfrei.

Aus meiner Sicht ist sie dies nicht, da sie implizit vorraussetzte, dass jeder Prozess die MS-CRT verwendet!

groovemaster schrieb:

Jochen Kalmbach schrieb:

Und was mein Beispiel macht wiederlegt exact diese Behauptung in der MSDN...

Nein, dein Beispiel belegt lediglich, dass du einen benutzerspezifischen Entry-Point definieren kannst und damit gewisse Festlegungen eines Default Frameworks aushebeln kannst. Glückwunsch!

Hä???? Die WinAPI hat überhaupt nichts mit der MS-CRT zu tun!!!
Wenn Du einen anderen Compiler verwendest, der in seiner Implementierung der CRT am Ende kein ExitProcess aufruft, dann stimmt die Doku auch nicht!
Man sollte bitte die WinAPI nicht mit Tricks in der CRT verwechseln!

groovemaster schrieb:

Dein Hinweis war zwar berechtigt, nur hättest du dazu schreiben sollen, dass dies nicht für "normale" Anwendungen gilt.

Unter "normal" verstehst Du halt die Microsoft-CRT...

groovemaster schrieb:

Jochen Kalmbach schrieb:

XP ruft nämlich bei einem "return" aus dem Main-Thread direkt "ExitThread" auf...

Sry, auch das kann ich der Doku nicht entnehmen. Vllt. kannst du ja mal die Quelle dazuschreiben.

Wie Quelle!? Du kannst dies einfach Debuggen, dann siehst Du es

PS: In C# hast Du übrigends genau das gleiche Verhalten wie in der WinAPI:

class MyClass
  {
    static void Thread()
    {
      while(true)
      {
        Console.WriteLine("Thread...");
        System.Threading.Thread.Sleep(100);
      }
    }
    static void Main(string[] args)
    {
      System.Threading.Thread t = new System.Threading.Thread(new System.Threading.ThreadStart(Thread));
      t.Start();
    }

Nur die MS-CRT erzeugt dieses Verhalten wie Du es beschrieben hast!

[groovemaster]

Jochen Kalmbach schrieb:

Naja... zumindest für Anwendungen welche die MS-CRT verwenden, da diese explizit ExitProcess aufruft

Und alle anderen CRT's, die sich an die WinAPI Doku halten.

Jochen Kalmbach schrieb:

Aus meiner Sicht ist sie dies nicht, da sie implizit vorraussetzte, dass jeder Prozess die MS-CRT verwendet!

Nein, tut sie nicht. Du verwechselst da was. Die Doku ist sozusagen die Referenz (wie zB ISO/IEC 14882 für C++). Und alle CRT's müssen sich daran orientieren und nicht umgekehrt.

Jochen Kalmbach schrieb:

Hä???? Die WinAPI hat überhaupt nichts mit der MS-CRT zu tun!!!

Korrekt und irgendwas Gegenteiliges hat auch niemand behauptet.

Jochen Kalmbach schrieb:

Wenn Du einen anderen Compiler verwendest, der in seiner Implementierung der CRT am Ende kein ExitProcess aufruft, dann stimmt die Doku auch nicht!

Nein, die Doku stimmt deshalb trotzdem. Nur entspricht die CRT dann nicht der Vorgabe. Das ist wie ein C++ Compiler, der sich nicht an den Standard. Niemand kann ihm das verbieten, du hast letztendlich aber mit den Konsequenzen zu leben.

Jochen Kalmbach schrieb:

Unter "normal" verstehst Du halt die Microsoft-CRT...

Nein. Unter normal verstehe ich CRT's, die sich an die Dokumentation halten. Übrigens, ich habe dein Programm auch mit GCC getestet und dabei das Verhalten festgestellt, was die Doku vorgibt.

Jochen Kalmbach schrieb:

Wie Quelle!? Du kannst dies einfach Debuggen, dann siehst Du es

Ääähh, ja klar, ich werde das Programm debuggen...
Wie wäre es, wenn du einfach das Stückchen Text aus der Doku postest, was dein Aussage belegt? Das meinte ich übrigens mit "Quelle".

Jochen Kalmbach schrieb:

Nur die MS-CRT erzeugt dieses Verhalten wie Du es beschrieben hast!

Wie ich bereits sagte, andere CRT's auch.

[emma-t]

- es gibt einen Primärthread im Prozess;
- dieser Primärthread kann beendet werden, während andere Threads weiterlaufen.

Das Beenden eines Threads an sich bewirkt nicht die Löschung des Thread-Objekts - ich vermute, dass das Primärthread-Objekt bis zum Ende des Prozesses erhalten bleibt, somit auch die zugehörige Thread-ID.

[Jochen Kalmbach]

groovemaster schrieb:

Jochen Kalmbach schrieb:

Naja... zumindest für Anwendungen welche die MS-CRT verwenden, da diese explizit ExitProcess aufruft

Und alle anderen CRT's, die sich an die WinAPI Doku halten.

Ich glaube wir reden aneinander vorbei...
In der Doku hier:http://msdn.microsoft.com/library/en-us/dllproc/base/terminating_a_process.asp
welche Du auch auszugsweise Zitiert hast, steht nichts dass dies Verhalten ausserhalb der CRT implementiert werden muss!!! Es beschreibt die WinAPI, wie sie sich verhält. Und diese Beschreibung ist definitiv falsch, da die WinAPI selber beim Verlassen des Primär-Threads ExitThread aufruft und somit selber dafür sorgt, dass der Prozess weiterlebt, wenn noch andere Threads existieren.
Das ist auch genau das gleiche Verhalten welches das .NET-Framework implementiert.
Ich werde aber heute abend mal in den Source schauen, dann kann ich Dir mehr sagen...

[Jochen Kalmbach]

Also... Windows macht absolut keinen Unterschied beim beenden der Threads!

Der "Initial-Thread" (so der Kommentar im Source) ruft ExitThread auf, wenn die Funktion (Entry-Point) zurückkehrt. Das ExitThread macht wiederum keine unterscheidung welcher Thread beendet wird. Es fragt lediglich via NtQueryInformationThread mit ThreadAmILastThread, ob dies der letzte Thread ist. Und nur dann wird ExitProcess aufgerufen.

Somit ist die Doku der WinAPI aus meiner Sicht falsch und ich werde dies so MS weiterleiten; dass sie den Hinweis aufnehmen sollen, dass die MS-CRT beim beenden des Hauptthreads ExitProcess aufruft und dies nicht eine eigenschaft der WinAPI ist.

[groovemaster]

Jochen Kalmbach schrieb:

Somit ist die Doku der WinAPI aus meiner Sicht falsch

Nunja, irgendwie scheint mir deine Herangehensweise falsch. Das ist aber meine persönliche Meinung. Du schaust in die Implementierung und weil diese nicht mit der Dokumentation übereinzustimmen scheint, sagst du einfach, dass die Doku falsch sei. Ich würde dann eher sagen, die Implementierung ist unzureichend. Aber die Antwort auf die Frage kennt wohl nur MS.
Bis dahin halte ich mich jedenfalls an die Doku und erwarte, dass der Prozess beendet wird, wenn ich main/WinMain beende. Dass dies bei deinem Beispiel zwar nicht so ist, macht mich schon etwas stutzig. Nur ist dieser Fall ein relativ unwahrscheinlicher. IdR versucht man ja, seine Threads kontrolliert zu beenden, bevor man den Primärthread beendet. Und benutzerspezifische Entry-Points werden wohl auch nur recht selten gebraucht. Wenn überhaput, dann ist das eher bei DLL's gebräuchlich.

Jochen Kalmbach schrieb:

und ich werde dies so MS weiterleiten; dass sie den Hinweis aufnehmen sollen, dass die MS-CRT beim beenden des Hauptthreads ExitProcess aufruft und dies nicht eine eigenschaft der WinAPI ist.

Mach das und poste bitte die Antwort hier.

[Jochen Kalmbach]

groovemaster schrieb:

Jochen Kalmbach schrieb:

und ich werde dies so MS weiterleiten; dass sie den Hinweis aufnehmen sollen, dass die MS-CRT beim beenden des Hauptthreads ExitProcess aufruft und dies nicht eine eigenschaft der WinAPI ist.

Mach das und poste bitte die Antwort hier.

... naja, das Problem ist nur, dass es dafür leider keinen "Organisations-Prozess" bei MS gibt, der auch eine Rückmeldung ermöglicht
Du kannst das zwar sagen (vielleicht auch noch direkt zum MVP Lead), aber wann und ob es umgesetzt wird ist die andere Frage).

[Jochen Kalmbach]

groovemaster schrieb:

Jochen Kalmbach schrieb:

und ich werde dies so MS weiterleiten; dass sie den Hinweis aufnehmen sollen, dass die MS-CRT beim beenden des Hauptthreads ExitProcess aufruft und dies nicht eine eigenschaft der WinAPI ist.

Mach das und poste bitte die Antwort hier.

So... hat zwar etwas gedauert, aber jetzt ist die Seite Online:
Terminating a Process
http://msdn.microsoft.com/library/en-us/dllproc/base/terminating_a_process.asp

Die Beschreibung wurde entsprechend angepasst... das "The primary thread terminates" wurde entfernt... jetzt heisst es:

- Any thread of the process calls the ExitProcess function. Note that some implementation of the C run-time library (CRT) call ExitProcess if the primary thread of the process returns.
- The last thread of the process terminates.