Version imprimable
Salut,
J'utilise cette fonction pour synchroniser des evenements sur des fonctions en récupérant l'index de l'évenement en retour.
Ces evenements proviennent de processus clients qui demandent l'instance d'un pipe d'un processus serveur pour lui ecrire un message
ça marche pas mal mais le premier client qui écrit n'est jamais detecté. Le deuxième oui. etc..
Une idée? ça me trotte je trouve pas!
Merci
Robux
Es-tu sûr que tu n'as pas une attente avant ta boucle d'attente principale, ou un problème du genre?
Salut,
Je traite mon WaitForMultipleObject dans un thread. En pas à pas j'entre dans le thread comme suit :
puis l'attente est infini sur la fonction Wait. Je lance mon premier client il ne se passe rien. j'en lance un deuxième le debug commence et je passe à la ligne suivante où i est définiCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26void DispatcherRoot::run() { bool lwait = false; DWORD i,dwWait,cbRet; bool fSuccess; while( !mStop ) { dwWait = WaitForMultipleObjects( kPipeCount, mPlatformSpecificData->hEvent, FALSE, // no wait for all INFINITE); i = dwWait - WAIT_OBJECT_0; // determines which pipes if (i < 0 || i > (kPipeCount - 1)) { LCTrace("Index pipe out of Range.\n"); continue; } // Je connais i donc je connais l'event et je traite dans une fonction } }
Donc le premier client est ignoré par le serveur. c'est génant.
Comme il s'agit de pipe voici le code des evenements et pipes créés :
RobuxCode:
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
41
42
43
44
45
46
47struct DispatcherRoot::DispatcherRootPlatformSpecificData { char buffer[kMessageBufferSize]; // buffer to store client requests struct { HANDLE hPipe; bool fPending; DWORD dwState; } hPipeStruct[kPipeCount]; OVERLAPPED ovr[kPipeCount]; HANDLE hEvent[kPipeCount]; CString pipeName; //The name of server pipe }; // Create pipes for(int i = 0; i < kPipeCount; i++) { mPlatformSpecificData->hEvent[i] = CreateEvent( NULL, TRUE, TRUE, NULL); if(mPlatformSpecificData->hEvent[i] == NULL) { LCTrace("Should not happend : CreateEvent failed with %d.\n", GetLastError()); return ; } mPlatformSpecificData->ovr[i].hEvent = mPlatformSpecificData->hEvent[i]; // je garde les event dans ma structure mPlatformSpecificData->hPipeStruct[i].hPipe = CreateNamedPipe( mPlatformSpecificData->pipeName, PIPE_ACCESS_INBOUND | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, kPipeCount, kMessageBufferSize, kMessageBufferSize, 0, NULL); mPlatformSpecificData->hPipeStruct[i].fPending = ConnectToNewClient(mPlatformSpecificData->hPipeStruct[i].hPipe,&mPlatformSpecificData->ovr[i]); if(!mPlatformSpecificData->hPipeStruct[i].fPending)// ConnectNamedPipe should return 0 for an OVERLAPPED pipe { LCTrace("ConnectNamedPipe has failed"); } mPlatformSpecificData->hPipeStruct[i].dwState = mPlatformSpecificData->hPipeStruct[i].fPending ? CONNECTING_STATE : READING_STATE; }
Tes événements sont créés signalés. À quel moment les resettes-tu ?
Que se passe-t-il si un client se connecte entre le moment où tu crées l'event et celui où tu le resettes ? (race condition)
Oui je reset les evenements dans la fonction ConnectToNewClient comme suit :
Code:
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
38bool ConnectToNewClient(HANDLE hPipe, LPOVERLAPPED lpo) { BOOL fConnected, fPendingIO = FALSE; // Start an overlapped connection for this pipe instance. fConnected = ConnectNamedPipe(hPipe, lpo); // Overlapped ConnectNamedPipe should return zero. if (fConnected) { printf("ConnectNamedPipe failed with %d.\n", GetLastError()); return 0; } switch (GetLastError()) { // The overlapped connection in progress. case ERROR_IO_PENDING: fPendingIO = TRUE; break; // Client is already connected, so signal an event. case ERROR_PIPE_CONNECTED: if (SetEvent(lpo->hEvent)) break; // If an error occurs during the connect operation... default: { printf("ConnectNamedPipe failed with %d.\n", GetLastError()); return 0; } } return fPendingIO; }
En testant pas à pas quand j'instancie tout mes pipe par le code du précedent message (CreateNamedPipe) puis ConnectToNewClient, J'arrive dans le code cidessus.
Ce qu'il se passe c'est que je passe systématiquement dans le cas : ERROR_PIPE_PENDING. Le setEvent se fait lui dans ERROR_PIPE_CONNECTED donc les resets ne se font que si les pipe sont coneectés donc occupés. logique non?
Je ne fais pas de SetEvent ou ResetEvent avant ça et j'ai testé avec les deux mon premier client n'est jamais detecté (ignoré par le service).
D'autre part, les exemple dans msdn font des createEvent sans faire ResetEvent ou SetEvent derrière. Je vois pas?
Merci!!
Robux
Je pense que tu ne fais pas tes ResetEvent() au bon endroit, et que tu as une race condition à cause de ça.
PS: Ça me parait bizarre ton truc: C'est le serveur qui se connecte aux clients? 8O
En fait chaque processus crée un pipe en INBOUND. Il ne s'agit pas de duplex.
Quand un processus veut parler à un autre il fait un CreateFile (donc il attrape une instantiation d'un pipe du processus auquel il s'adresse et il écrit dedans)
Comme il y a un processus central à qui tout le monde vient parler alors c'est le serveur. Les autres les clients.
De plus le serveur, pour répondre, adopte la même attitude, il attrape une instantiation d'un pipe du client et écrit dessus. C'est sa réponse. En fait le fichier est partagé par tout les processus. Ils ont tous la même attitude sauf que le serveur à un nom défini et tout le monde lui demande des trucs.
En fait la fonction ConnectToNewClient ne contient que un ConnectNamedPipe qui crée une connection Evénement - Pipe. Mais les clients eux se connectent tous seuls au serveur en faisant véritablement un CreateFile.
Voilà pour l'explication.
Sinon ne perdons pas de vue que mon code fonctionne et que le problème porte juste sur la detection de l'écriture du PREMIER client au serveur.
Merci!
Robux
Un code avec une race condition "fonctionne"... la plupart du temps.
Là, c'est au niveau conception et algorithme que tu dois vérifier qu'on ne peut pas resetter l'événement entre le moment où le client envoie au serveur et celui où l'événement est vérifié.
PS: Comment détectes-tu qu'un client se connecte, en fait?
:D
1/ Il va falloir que tu m'explique en quoi consiste le Reset d'evenement car j'ai lu les doc pipe et event de msdn et je crois qu'il me manque un truc. Où le mettre? après le Create?
2/ En fait quand un pipe est créé par CreateNamedPipe en OVERLAPPED alors ConnecteNamedPipe demande en second parametre un pointeur sur une structure OVERLAPPED. structure à un membre hevent que j'initialise justement à l'evenement créé. le premier paramètre étant le Handle sur le pipe crée.
C'est la connection Evenement - Pipe dont je te parlais au précédent message. Donc dés qu'un client fait un CreateFile il a attrapé une instantiation d'un pipe serveur, un évenement est créé et la fonction de synchronisation WaitForMultipleObjects (qui a aussi l'événement, en fait un tableau d'événement ) réagit et sors de son Wait INFINITE.
Je le comprend ainsi. C'est clair?
Concernant le Reset file moi un piste ou le mettre etc...stp
Je reviendrais en mettant mon code pour qui regroupe tout ce que j'ai déjà mis mais dans l'ordre ça sera plus clair.
Robux
Je crois qu'on ne s'est pas compris.
Les Events que tu utilises sont anonymes et créés en Manual Reset, donc il y a forcément un truc qui les resette quelque part, ou bien ils sont détruits et re-créés à chaque fois.
Si ça n'est pas fait, WaitForMultipleObjects() retournera toujours immédiatement, une fois qu'un événément aura été signalé pour la première fois.
Et moi, je te demande de me montrer l'endroit où ils sont resettés, ou détruits&re-créés.
Je ne faisais qu'expliquer mon code, justement je ne sais pas comment gerer ce reset.Citation:
Envoyé par Médinoc
Il y a un SetEvent dans la fonction ConnectToNewClient (nom pas très juste.. je te l'accorde). Je ne sais pas s'ils sont correctement fait. :aie:
Peut être ne devrais pas me mettre en manual reset?
Qu'est ce qui determine si on devrait se mettre en manual reset ou pas? :roll::roll::roll:
Robux
Là par contre, je sèche.