Discussion :

[alpha_one_x86]

Bonjour, je suis parti de l'exemple:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
Vu que j'ai la boucle d'event autre par (programme Qt), j'ai essayer de le faire sans cette mini boucle d'event:
http://pastebin.com/h4MT9YZA
Hors la nouvelle connexion de quelqu'un n'est jamais détecté!
Et donc les functions de traitement des données ne sont jamais connecté.

Je ne sais pas comment le faire. J'ai besoin pour chaque logiciel connecté sur le pipe nommé, de communiquer juste avec lui dans le protocol spécifique.
Merci d'avance de votre aide.

[alpha_one_x86]

Il doit y avoir un moyen de chopper un event sans avoir accés à la boucle d'event, si non ca veut dire qu'aucun plugin ne peu utilisé les events

[Andnotor]

Si la "mini boucle" à laquelle tu fais référence est while (1), celle-ci est obligatoire, sinon tu n'auras qu'une connexion puis plus rien...

L'event devrait être nommé pour pouvoir le partager entre application. Mais celui-ci est utilisé pour la synchro interne du serveur et je ne vois pas trop pourquoi tu veux le partager

[alpha_one_x86]

Sauf que ce while pour maintenir le main() ouvert pour pas que le programme ce refait, est déjà fait autre part. (dans un programme Qt c'est QCoreApplication)
Et donc ça fait un comportement bloquant qui est génant ici.

L'event en lui même ne doit pas étre partagé.

Voila le code en Qt:
http://pastebin.com/5nCNnc1x
Que j'essaye de refaire en C.

Je ne sais pas refaire la ligne 139, mais tout le reste du code marche.

[Andnotor]

Un serveur NamedPipe mono-thread ne veut pas dire que tu peux simplement ajouter sa gestion à ta tâche principale. Il doit tout de même être dans une tâche secondaire
Cette boucle n'a rien à voir avec la boucle de messages de l'application !

Perso je préfère travailler en multi-thread, mais dans les deux cas, il y a une tâche dédiée à la gestion des connexions.

En mono, elle se charge de tout; connexion et communication avec les clients. Une queue de demandes est remplie et son remplissage/vidage est synchronisé par event (ConnectNamedPipe n'est pas bloquant) alors qu'en multi, ConnectNamedPipe est bloquant, mais un nouveau thread est créé pour chaque client.

[alpha_one_x86]

Donc ça serai un serveur NamedPipe mono-thread qu'il me faudrai. Mais j'y suis pas pas arrivé. (voir code en haut)

J'arrive pas à overlapped l'event pour appeller une function à la connexion d'un clients (et tout le reste je sais encore moins comment ça marche)

[Andnotor]

J'ai dit une connerie au niveau de ConnectNamedPipe bloquant ou non qui dépend en fait du mode de création du pipe (PIPE_WAIT)

Donc ça serai un serveur NamedPipe mono-thread qu'il me faudrai.

C'est ce que tu a fait, mais sans le thread

Je ne connais pas QT ni ne maîtrise ce mode de NamedPipe, mais si j'étais toi, je commencerais par créer un thread dédié et repartirait de l'exemple MS sans en supprimer des parties en pensant que...
Là il me semble qu'en ayant supprimé l'event, tu n'attends tout simplement pas qu'une donnée soit disponible pour continuer...

[alpha_one_x86]

Là il me semble qu'en ayant supprimé l'event, tu n'attends tout simplement pas qu'une donnée soit disponible pour continuer...

C'est aussi ce que je pense, mais hélas je doit retourné les events dans le thread de base, je doit donc maitrisé thread ET syncro-interthread. Ce que je connait pas en win32. Ni l'un ni l'autre, je préfére donc faire au plus simple.

[Andnotor]

Si tu nous disais la finalité parce que là j'ai l'impression que tu mélanges tout !

Si tu veux synchroniser plusieurs tâches (une liste remplie par le serveur NP et lue/vidée par la tâche principale) il faut en effet un verrou, par event, par section critique, etc. Mais ce verrouillage intervient uniquement lorsque le serveur à quelque chose à écrire ou que la tâche principale est en train de lire et est indépendant de la gestion interne du serveur. Ce n'est pas le même event !

[alpha_one_x86]

La finalité est de développé une classe generique pour tout logiciel de copie de fichier en C/C++ comme copy handler, pour écouté sur le pipe nommé server les clients qui vienne s'y connecté et communiquer avec la norme catchcopy.

La 1ére intégration vas étre sur le logiciel copy handler (je vais ajouter la classe, et appellé moi même les bonnes fonctions). Mais pour l'instant je teste avec un logiciel basique en Qt.

Les classes parents pour l'héritage, et donc avoir une interface entre le code que je fait et l'application sont ici:
https://github.com/alphaonex86/Copy-...c/ch/catchcopy
(Ici C++, même si le code dedans est en C)

[Andnotor]

Ici C++, même si le code dedans est en C

Je ne maitrise pas plus le C/C++. Moi, c'est Delphi

Mis à part (les APIs et raisonnements sont identiques)

• Par définition, mono veux dire un à la fois (ou un après l'autre). Pour des copies de fichiers, on peut penser qu'on y gagnerait en les lançant en parallèle (multi-thread). Le choix du mode n'est peut être pas pertinent.
• A quoi sert le pipe ? à envoyer une commande (source -> destination) ou le fichier lui-même ?
• Tu ne réfléchis pour l'instant que sur le serveur. Comment comptes-tu procéder côté client ? L'accès à un Pipe utilise déjà des fonctions génériques: CreateFile, WriteFile, ReadFile, CloseHandle (ouverture du pipe, requête, réponse, fermeture).
• Tu veux manifestement du bi-directionnel, mais le client n'a pas de boucle de réception... à moins qu'il soit lui-même serveur !