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