... pour une utilisation dans un serveur de réseau multithreadé.
Je veux transmettre des données entre plusieurs threads. Actuellement, j'utilise des sockets, avec le bloc-fil maître sur Select () et les travailleurs bloquants sur RECV (), bien que je pense qu'il y a probablement des moyens plus avancés ou préemballés de manipuler cette tâche en C ++.
5 Réponses :
Vous pouvez essayer la bibliothèque ACE qui navère avec des tuyaux et des files d'attente de messages spécialement adaptées à la communication inter-thread.
** ACE signifie environnement de communication adaptatif *
J'aurais des threads de travailleur en attente d'une piscine de fil.
Ensuite, le maître en attente sur SELECT (pour les deux lectures et les écritures).
Comme les données viennent que le maître ajoute des travaux au pool de threads. Comme chaque travail est ajouté, un thread réveil exécute le travail et retourne à la piscine. De cette façon, vous ne bloquez pas les threads en attente de ports spécifiques avec RECV () et un ensemble fixe de filets d'enfants peut gérer tout le trafic entrant.
CurrentL Libs qui supportent cette fonctionnalité dans des objets prêts à l'emploi:
libhread de plan9port comprend une structure de canal qui sera très similaire; Prenez note de la contribution de Russ Cox à la fois plan9port et Go-Lang, ainsi que le Libthead Historique :
se déplacer dans une direction différente, Luca Cardelli et Rob Pike développé
les idées dans le CSP dans le mini-langage de grincement [4] pour générer un utilisateur
Code d'interface. (Ce grincement est distinct de la petite grille
Mise en œuvre.) Pike a ensuite élargi grinçant dans les
Langage de programmation NewsQuak [5] [6] Qui engagez le plan 9 d'Alef [7]
[8], Limbo de Inferno [9] et Google GO [13].
À un moment ultérieur de l'histoire du Plan 9, il est devenu trop d'effort pour maintenir l'infrastructure pendant deux langues. Alef a donc été interrompu et les constructions de la CSP portées à C sous forme de libhead.
Donc, comme les canaux GO sont essentiellement un descendant direct de Libthread, je ne pense pas que vous trouverez quoi que ce soit plus similaire :)
" Un canal est une file d'attente tampon ou non coupée pour les messages de taille fixe " ( Plan9 thread ).
Il y a une file d'attente tamponnée dans le TBB: Concurrent_bounded_Quue .
Et je viens de mettre en place une sorte de canal non volé en C ++ 11: https: //gist.github. com / artemgr / 7293793 . Bien qu'une implémentation plus générique serait de créer une paire de références de références (comme dans le Felix mk_ioschannel_pair ), une pour chaque extrémité du canal, afin d'interrompre toute attente au cas où l'autre extrémité du canal n'existe plus.
Peut-être Zeromq pourrait valoir la peine d'être vérifiée. Il a un canal «INPROC» qui vous permet de communiquer entre les threads. Bien sûr, vous ne pouvez envoyer que des chaînes entre les threads, non les objets, mais d'autre part, il prend en charge les autres transports tels que TCP / IP (vous pouvez donc facilement communiquer entre les processus sur un réseau), est une plate-forme transversale et dispose de liaisons de langue pour la plupart des courants. Langues.
Y a-t-il une raison pour laquelle Recv bloque? Je ne pensais pas que vous deviez bloquer à la RECV, la même chose peut être vraie pour sélectionner
Ce n'est pas un bug. Il bloque sur RECV () lorsqu'il attend les données du fil principal. Je n'ai dit que cela pour mieux expliquer l'architecture du programme.
Content de voir que je ne suis pas le seul à apprécier des "canaux".