Discussion :

[NiamorH]

Je viens de me heurter à un deadlock avec ce programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <Windows.h>

DWORD WINAPI EntryPoint( void * )
{
	MSG msg;
	while ( GetMessage( &msg, NULL, 0, 0 ) )
	{
	}

	return 0;
}

int WINAPI WinMain( HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR lpCmdLine,
    int nCmdShow )
{
	DWORD id;
	HANDLE th = CreateThread( NULL, 0, EntryPoint, NULL, 0, &id );
		
	//Sleep( 1000 );

	PostThreadMessage( id, WM_QUIT, 0, 0 );
	
	WaitForSingleObject( th, INFINITE );
}

Le thread créé ne reçoit jamais mon message.
Il suffit que je décommente le Sleep pour que je reçoive toujours mon message.

Alors je me demande dans quelle mesure mon thread est créé s'il n'est pas cappable de recevoir mes messages... Rien n'est dit sur la msdn. Cela m'oblige à instaurer un mécanisme d'attente pour être sûr que mon thread est arrivé à la boucle des messages avant de lui en envoyer.

[ram-0000]

Dans Winmain, tu créé un event, tu créé ton thread et tu te met en attente bloquante (ou avec timeout) sur ton event.

Quand ton thread est parti, il signale ton event (cela doit être une variable globale à Winmain et à ton thread ou alors une variable du contexte du thred).

Winmain est libéré, il peut détruire l'event (plus utile) et poster le message au thread.

[NiamorH]

C'est ce que j'ai essayé mais visiblement, ça ne marche que 10 fois sur 11. J'arrive quand même à des deadlock avec ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <Windows.h>

HANDLE hevent;

DWORD WINAPI EntryPoint( void * )
{

	SetEvent( hevent );

	MSG msg;
	while ( GetMessage( &msg, NULL, 0, 0 ) )
	{
	}

	return 0;
}

int WINAPI WinMain( HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR lpCmdLine,
    int nCmdShow )
{
	hevent = CreateEvent( NULL, TRUE, FALSE, NULL );

	DWORD id;
	HANDLE th = CreateThread( NULL, 0, EntryPoint, NULL, 0, &id );
	
	WaitForSingleObject( hevent, INFINITE );

	PostThreadMessage( id, WM_QUIT, 0, 0 );
	
	WaitForSingleObject( th, INFINITE );
}

Etrange non ? Il semblerait que même une fois rentré dans EntryPoint, la file de message ne soit pas fiable.

[Médinoc]

Fais un PeekMessage() avec le flag PM_NOREMOVE au début de ton thread, AVANT le SetEvent().
Ainsi, tu seras sûr que la file de messages correspondant au thread a été créée (elle n'est créée que lors du premier appel à une fonction qui s'y rapporte).

PS: À ta place, j'utiliserais WaitForMultipleObjects() sur l'event et le thread, histoire de choper une fin anormale du thread (même si ce n'est pas censé arriver).

[NiamorH]

Très bonne idée le peekmessage

elle n'est créée que lors du premier appel à une fonction qui s'y rapporte

C'est documenté quelque part ? je n'ai pas trouvé dans la msdn.

Et oui, tu as raison pour le wait multiple.


En fait je suis en train de recoder un truc que j'avais fait il y a un peu plus d'un an maintenant, mais que j'ai bêtement perdu...

Et au fur et à mesure, les souvenirs me reviennent (de mauvais souvenirs) sur la fiabilité de PostThreadMessage.

Il me semble me rappeller que même une fois bien lancé, si on envoie au thread plusieurs messages à la volée consécutivement, il se peut qu'il en perdre quelques uns au passage...

Du coup j'avais réimplémenté ma propre file de message, basée sur un conteneur standard encapsulé par des sections critiques. Et la je recevait bien tous mes messages d'un thread à l'autre.

[Médinoc]

C'est documenté quelque part ? je n'ai pas trouvé dans la msdn.

Ahem! Doc de PostThreadMessage()