Salut � tous,
Je suis en face d'une situation un peu inexplicable pour le moment :
j'ai un thread qui execute le bout de code suivant:
A noter que DecodeIsFinished n'est JAMAIS signal�!
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
34
35
36
37
38
39
40 void DMX::doTimer() { CMesurePrecision myT; DWORD ret; FILE* tmp; int cpt = 0; while(1) { myT.Start(); ret = WaitForSingleObject(decodeIsFinished,10); double timeFordecode2 = myT.GetTimeFromStart(); ResetEvent(decodeIsFinished); cpt++; if (ret==WAIT_TIMEOUT) { if (ACTIVATE_TIMEOUT) { quitNow=true; timeFordecode=myT.GetTimeFromStart(); tmp = fopen("mydeduglog.txt","a+"); fprintf(tmp,"Timeout Reached in %.2f and %.2f\n",1000*timeFordecode2,1000*timeFordecode); fclose(tmp); } } //printf("sleep time= %fms , timeout=%d\n", a*1000, out); } }
En �xecutant cette boucle, on s'attendrait � ce qu'on arrive toujours en timeout avec des valeurs proches du timeout de 10ms qui est cod� en dur dans le programme.
Pourtant, voil� ce que j'ai en sortie dans mon fichier texte:
Timeout Reached in 3.60 and 3.60
Timeout Reached in 3.55 and 3.55
Timeout Reached in 3.56 and 3.56
Timeout Reached in 3.55 and 3.56
Timeout Reached in 3.53 and 3.53
Timeout Reached in 3.56 and 3.56
etc etc
Ce r�sulttat arrive sur 3 Pcs de tests...configurations vari�es
Plus int�ressant encore, sur un autre PC, le m�me code donne le r�sultat suivant:
Timeout Reached in 10.20 and 10.20
Timeout Reached in 10.64 and 10.64
Timeout Reached in 10.45 and 10.45
Timeout Reached in 10.82 and 10.82
etc
Ce qui est un comportement nettement plus normal...
WaitForSingleObject fait partie de kernel32.dll, y-aurait-il quelque chose � ce niveau l�? Je suis un peu perdu sur comment debugger ce truc maintenant...
Ah oui, tous les PCs on la m�me version de kernel32.dll...
Merci d'avance pour toute aide, info ou id�e sur le sujet!
++
Frantz
Partager