select()

Das ist ja klar, daß der neue Thread den Aufrufenden blockiert, wenn Du mit WaitForMultipleObjects darauf wartest. Du kannst ja auch WaitForSingleObject nehmen. Weiterhin solltest Du nicht lange warten, sondern nur sehr kurz und danach die Messageverarbeitung anstoßen:
Code:
DWORD dwWaitResult = WAIT_TIMEOUT;
   
   while(dwWaitResult != WAIT_OBJECT_0)
   {
   	dwWaitResult = WaitForSingleObject(pi.hProcess, 10);
   	//Applikations-Messagequeue verarbeiten
   	if(PeekMessage(&AppMsg, 0, 0, 0, PM_NOREMOVE))
   	{
   		GetMessage(&AppMsg, 0, 0, 0);
   		TranslateMessage(&AppMsg);
   		DispatchMessage(&AppMsg);
   	}
   }
 
bin noch nicht so ganz fitt mit Threads ...
kannst du das ein bischen genauer erklären ? ^^
gruß ....

// Edit
WaitForSingleObject(hThread,2000);
das funktioniert ja, ist mir auch klar warum ... Nur wie bekomme ich das hin das der dauerhaft hat im Thread bleibt und die neuen recv in das Listenfeld schreibt, ohne das die Grafik abschmiert .
 
Zuletzt bearbeitet:
Warum wartest Du denn überhaupt auf den Thread? Der Schreibt dich selbständig Daten in die Listbox und beendet sich, wenn er fertig ist. Laß das WaitForMultipleObjects einfach weg, wenn du das Ergebnis des Threads nicht brauchst.

Mit dem Erzeugen eines Threads (engl. für Faden) läuft dieser Thread parallel zu dem ursprünglichen, es laufen dann also 2 Threads in diesem Prozess. Das Umschalten zwischen diesen Threads zur Ausführung macht das Betriebssystem. Wenn die Threadfunktion beendet ist, ist auch der Thread beendet. Daher mußt Du nicht warten, bis der Thread beendet ist, bevor Du mit Deinem ursprünglichen Thread weitermachst.
 
Hi, oh man hast recht warum warte ich auch auf den Thread *autsch...
Naja jetzt habe ich nur noch 1 Problem. der nimmt nur ein recv an
Code:
DWORD WINAPI recvThread(LPVOID data){


  CListBox * pMsg = (CListBox *)data;

    pMsg->AddString("Running : Thread.");



	while(1){

		rc = recv(s,buf,sizeof(buf),0);
		pMsg->AddString(buf);

	}
 
Und was passiert dann? Eigentlich sollte er die Schleife endlos durchlaufen.
Vielleicht solltest Du den Rückgabewert von recv auswerten. Wenn der <= 0 ist, dann verlasse die Schleife und beende den Thread, am besten, indem Du den Rückgabewert von recv mit return zurückgibst.
Das mir den globalen Variablen ist auch nicht so gut. Du solltest z.B. die Variable 's' als Membervariable des Dialogs anlegen. Dann erzeugst du ein struct, welche den Wert von 's' sowie den Zeiger auf Deine ListBox enthält. Der Threadfunktion übergibst Du dann einen Zeiger auf das struct.
EDIT: Ich habe gerade gesehen, daß Du in beiden Threads etwas mit der Variable 's' machst. Das ist immer sehr problematisch, wenn 2 parallel laufende Threads auf eine Variable schreiben!
EDIT2: Ich nehme das zurück, im erzeugten Thread scheint die Variable nur gelesen zu werden. Aber: Du startest erst den Thread, dann erzeugst Du den Socket, der im thread verwendet wird. So kann es passieren, das der Socket noch nicht erzeugt ist, wenn recv zum Ersten Mal aufgerufen wird. -> Erst den Socket erzeugen, dann den Thread starten. So etwas wird übrigens verhindert, wenn Du nicht mit globalen Variablen arbeitest.
 
Zuletzt bearbeitet:
Danke wegen der Globalen variablen.

Das Problem lag einfach an meinem Server...
Der durchläuft alle clients und guckt immer ob da ein send oder ein connect war.
Das Problem war aber das ich da geschrieben habe send(clients[ i ],buf,strlen(buf),0)
<< und der kam nie wieder zum eigentlich Client, weil der nichts sendet, und auch kein neues Connect macht ^^.

Nochmals vielen Dank !
 
Zurück