read aussi, vu que les sockets AF_UNIX sont des mécanismes d'IPC.
Yep, tout à fait.
Après, j'imagine qu'un segment de mémoire partagé est peut être plus performant qu'une socket (mais ce n'est que présomption)
Donc, mmap serait moins efficace dans ces cas que read? Cela n'impliquerait-il pas d'avoir une configuration pour read adéquate?
Bein, à mon taf on a du hard avec 8MiB de RAM. Autant te dire que mapper un fichier ne serait ce que de 1 ou 2 MiB à coup de mmap() met un vilain coup au système :-)
Pour ajouter de l'eau à ton moulin, dans ton sens, si tu mappes une zone mémoire entre deux processus, il va aussi te falloir gérer les accès concurrentiels, et du coup, utiliser un socket est nettement plus simple (c'est, en gros, un pipe), mais sera effectivement plus lourd qu'un mémoire partagée entre 2 processus.
Bien sûr, mais disons que le segment de mémoire partagé ne t'impose pas un scénario/protocole de communication contrairement au socket (aka proc-A envoie un message X à proc-B et bloque ensuite en l'attente d'une réponse Y).
A l'inverse, l'utilisation de sendmsg() avec un socket peut faciliter le développement (puisque les messages transmis sont directement mappable sur une structure C)... chose qui reste cependant possible avec un mmap() en utilisant un cast.
Puisque le fond de ton message semble concerné l'IPC, je vais dériver un peu sur ce sujet.
A mon humble opinion, il n'y a pas de solution miracle ou d'IPC à tout faire. En vrac et sans être exhaustif, je dirai que:
Si tu veux qu'un processus X offre un "service" à un process Y sans connaitre Y au préalable, je partirai sur des sockets unix en effet.
Si tu veux échanger des données que tu vas au préalable manipuler à coup de transformation de pointeur, mmap() est probablement plus adapté.
Si le système cible est performant (au minimum une carte avec un ARM AXX), je partirai sur un composant plus haut niveau:
dbus est puissant mais particulièrement pénible à utiliser.
LCM et ZCM sont pas mal, plutôt performant mais s'appuie sur du code généré à partir de description textuelle des messages... faut aimer.
ubus est un système d'ipc light: pas énormément de fonctionnalité, mais ça peut suffire.
... il y en a d'autres .. à toi de voir ;-)
Pour conclure, en 2019, je m'embêterai pas à écrire moi même un système d'IPC à moins que:
* Ce soit un délire personnel, pour le plaisir (mais faut être un peu maso ;-).
* Le système cible soit vraiment très contraignant (peu de RAM en particulier).
[^] # Re: quelques pistes ...
Posté par LaBienPensanceMaTuer . En réponse au message difference entre mmap() et read(). Évalué à 3.
Yep, tout à fait.
Après, j'imagine qu'un segment de mémoire partagé est peut être plus performant qu'une socket (mais ce n'est que présomption)
Bein, à mon taf on a du hard avec 8MiB de RAM. Autant te dire que mapper un fichier ne serait ce que de 1 ou 2 MiB à coup de mmap() met un vilain coup au système :-)
Bien sûr, mais disons que le segment de mémoire partagé ne t'impose pas un scénario/protocole de communication contrairement au socket (aka proc-A envoie un message X à proc-B et bloque ensuite en l'attente d'une réponse Y).
A l'inverse, l'utilisation de sendmsg() avec un socket peut faciliter le développement (puisque les messages transmis sont directement mappable sur une structure C)... chose qui reste cependant possible avec un mmap() en utilisant un cast.
Puisque le fond de ton message semble concerné l'IPC, je vais dériver un peu sur ce sujet.
A mon humble opinion, il n'y a pas de solution miracle ou d'IPC à tout faire. En vrac et sans être exhaustif, je dirai que:
Si tu veux qu'un processus X offre un "service" à un process Y sans connaitre Y au préalable, je partirai sur des sockets unix en effet.
Si tu veux échanger des données que tu vas au préalable manipuler à coup de transformation de pointeur, mmap() est probablement plus adapté.
Si le système cible est performant (au minimum une carte avec un ARM AXX), je partirai sur un composant plus haut niveau:
Pour conclure, en 2019, je m'embêterai pas à écrire moi même un système d'IPC à moins que:
* Ce soit un délire personnel, pour le plaisir (mais faut être un peu maso ;-).
* Le système cible soit vraiment très contraignant (peu de RAM en particulier).