User-Interface Thread

[obulus]

Hallo

Möchte gerade meinen ersten User-Interface Thread erzeugen. Habe mir dazu ein Beispiel rangezogen.

Mit AfxBeginThread erzeuge ich mir den Thread von einer CWinThread abgeleiteten Klasse:

CDialogThread *dialogThread = (CDialogThread*)
 (AfxBeginThread(RUNTIME_CLASS(CDialogThread)));

Doch leider bleibt mein Programm im Aufruf hängen und zwar in thrdcore an der Codestelle:

VERIFY(::WaitForSingleObject(startup.hEvent, INFINITE) == WAIT_OBJECT_0);

Weiß noch nicht genau was ich da noch falsch mache, da ich es genau nach Beipiel implementiert habe. Jemand einen Tipp?

[Martin Richter]

Icvh würde mal sagen, dass Dein Thread eben nicht startet.
Setz mal einen Breakpoint auf Deine InitInstance Methode.
Welche Methoden in der Klasse hast Du denn überschrieben?

[obulus]

Setz mal einen Breakpoint auf Deine InitInstance Methode.

Habe ich. Bis dorthin komme ich gar nicht.

Welche Methoden in der Klasse hast Du denn überschrieben?

Nur die InitInstance Methode

[obulus]

Ok. Jetzt habe ich noch was rausgefunden. Ich habe "AfxBeginThread" innerhalb von InitInstance meiner Applikation aufgerufen. Der Grund wieso das ganze hängen bleibt. Wenn ich dies später aufrufe funktioniert es. Aber der Thread soll gleich ab Start erzeugt werden. Wie stelle ich das an?

[Martin Richter]

Eigentlich ist das kein Problem einen Thread sofort so zu starten.
Ich mache dies auch in manchen Prozessen Workerthreads vor der eigentlichen UI zu starten.

Kannst Du das in einem Mini-Beispiel (Nur Wizard) auch reproduzieren Oder gibt es evtl. noch andere Abhängigkeiten.

[hustbaer]

Innerhalb von InitInstance der Applikation sollte kein Problem sein.
Innerhalb von InitInstance einer DLL geht dagegen nicht.
Genauso wie es in statischen Konstruktoren eine schlechte Idee ist.

[obulus]

Innerhalb von InitInstance einer DLL geht dagegen nicht.

Dann ist genau das mein Problem. Da ich eine DLL habe.

[Martin Richter]

Dann kannst Du das für InitInstance knicken. InitInstance läuft in DllMain, Aber die DllMain Eintrittspunkte werden synchronisiert. D.h. nur ein Thread zu einer Zeit.
Du kanst den Thread starten, aber laufen wird er erst, wenn InitInstance verlassen wird und genau hier geht dann die MFC nicht mehr, weil die zumindest das Starten abwartet.

Entkopple Laden der DLL und Thread. Bau noch eine Init Funktion ein, die nach dem Ladne der DLL aufgerufen werden muss...

[obulus]

Bau noch eine Init Funktion ein, die nach dem Ladne der DLL aufgerufen werden muss.

Hatte ich fast schon befürchtet. Ok werde ich wohl so machen müssen. Vielen Dank für die Antworten

[hustbaer]

Was man machen kann, ist den Thread via CreateThread zu starten, und dann ggf. die CRT selbst zu initialisieren.
Der Thread läuft dann zwar auch erst an, nachdem InitInstance der DLL beendet wurde, aber zumindest bleibt der CreateThread nicht hängen.

(AfxBeginThread bleibt hängen, weil AfxBeginThread intern selbst darauf wartet, dass der Thread angefangen hat zu laufen - was dann natürlich zu nem Deadlock führt, wenn man es aus DllMain/InitInstance einer DLL verwendet)

[obulus]

Also statt AfxBeginThread verwende ich CreateThread. Aber wie initialisiere ich die CRT selbst?

[Jochen Kalmbach]

Das *initialisieren* ist nicht das Problem... das geschieht automatisch, wenn Du eine CRT-Funktion aufrufst (die es braucht)!
Das problem ist nur, dass Speicherlecks entstehen, wenn Du die CRT für diesen thread nicht "deinitialisierst". Das machst Du einfach mit "_endthread()".

[Martin Richter]

Es spricht aber auch nichts dagegen _beginthreadex zu verwenden.

[hustbaer]

Bei _beginthreadex war ich mir nicht sicher, ob der nicht intern wieder auf den gestarteten Thread wartet, daher hab ich CreateThread geschreibt

Das problem ist nur, dass Speicherlecks entstehen, wenn Du die CRT für diesen thread nicht "deinitialisierst". Das machst Du einfach mit "_endthread()".

Jo, stimmt, haste Recht