Bonjour Guillaume,
Tu as écrit:
>Cela fait donc beaucoup de moyens de communiquer, mais je ne vois pas
>quel moyen est le plus approprié pour écrire telle ou telle application.
C'est parce que deux choses interviennent dans le choix de tel ou tel moyen. Le
plus important est le fait que le programmeur choisira toujours le moyen avec
lequel il se sentira le plus à l'aise. De ce fait, vu qu'on peut se sentir plus
à l'aise avec tel moyen plutôt que tel autre, on aura moins de souci à
déboguer. Ensuite, mais seulement ensuite, vient le fait qu'on trouvera tel ou
tel moyen plus efficace que tel ou tel autre.
>Par exemple, pouvez vous me dire quels types d'applications utilisent :
>- les tubes
Comme le disait Tarik, ce sont principalement des systèmes de type
producteur(s)/consommateur(s). Le tube étant monodirectionnel, à l'entrée, tu
mets un ou plusieurs producteurs, et à la sortie, tu mets un ou plusieurs
consommateurs.
Dans le cas où chaque producteur écrit des données par paquets et où
l'intégrité de chaque paquet doit être respectée, tu mettras un mutex à
l'entrée du tube, de sorte que chaque producteur y aille à son tour. Le
problème du tube est qu'il est généralement de petite taille et que cette
taille n'est pas ajustable. Il se peut donc que ledit tube ne permette pas de
tenir la cadence de producteurs/consommateurs trop rapides pour lui. Exemple
typique: l'entrée du tube est alimenté par un driver qui, comme c'est un
driver, ne peut se permettre d'avoir des tampons trop grands et qui, de ce
fait, doit pouvoir fournir ses données très rapidement. Si à la sortie du tube,
tu as un consommateur qui consomme à une vitesse irrégulière, il se peut fort
bien que le tube s'engorge et que tu perdes des paquets à la sortie.
>- les sockets locaux (parce que les sockets internet je connais)
C'est un moyen plus simple que de mettre deux tubes: l'un dans un sens et
l'autre dans l'autre parce qu'un socket, c'est bidirectionnel. Cependant, comme
le dit justement Tarik, il faut un processus qui commande, (le serveur), et
ceux qui suivent, (les clients).
Avantage du socket local par rapport au tube: La taille de ses tampons
d'émission et réception est ajustable. Pour de la transmission vidéo, j'ai même
vu des sockets, (locaux ou même ethernet) avec des tampons d'émission/réception
de 2 mo.
>- les segments de mémoire partagée et les sémaphores
C'est dans le cas où tu as un assemblage de processus qui sont tellement
interdépendants les uns des autres que le classique schéma de
producteur/consommateur ne peut s'appliquer. Je n'ai pas d'exemple en tête mais
d'une manière générale, quand la production d'une grosse quantité de données
peut servir à un autre processus qui lui-même va produire autre chose dont on
aura besoin plus tard. Du coup, on utilisera des sémaphores ou de simples mutex
pour protéger l'espace de mémoire.
>- les messages
Ils peuvent être pratiques pour gérer des événements en provenance de
l'utilisateur mais ils sont généralement assez lourds. Ce moyen de
communication fait penser à la manière dont des applications win32 communiquent
avec leur utilisateur: chaque bouton appuyé, déplacement de souris, pression ou
relâchement d'une touche du clavier, correspond à un message qui est envoyé à
l'application.
Mais j'avoue ne pas avoir encore utilisé ce mécanisme sous linux. C'est
seulement sous win32 que je m'en suis servi. Et encore, je l'ai fait uniquement
parce que dès que tu te connectes à une interface utilisateur, tu sais qu'elle
fonctionnera comme ça donc, tu t'y calques.
Mais globalement, bien faire attention à l'approche qui consisterait à être
trop catégorique en se disant "J'ai tel type d'application à écrire donc
j'utiliserai tel moyen plutôt que tel autre". Parce qu'en réalité, dans
beaucoup de cas, (pas tous quand même), les moyens de communication sont
interchangeables. Ne pas non plus confondre les moyens de communications:
tubes, sockets, mémoire partagée, messages, avec les moyens de synchronisation:
signaux, mutexes, sémaphores, ...
Bonne journée. @+ ChD
_______________________________________________
Liste de diffusion CarrefourBLinuX
[email protected]
http://lists.freearchive.org/mailman/listinfo/carrefourblinux
Pour s'inscrire par courriel :
'mailto:[email protected]?subject=subscribe'
Pour se retirer de la liste par courriel :
'mailto:[email protected]?subject=unsubscribe'
Archives : http://lists.freearchive.org/pipermail//carrefourblinux
Anciennes archives (Yahoogroupes) :
http://fr.groups.yahoo.com/group/carrefourblinux/messages
Rechercher : http://lists.freearchive.org/cgi-bin/search.cgi
Signets : http://fr.groups.yahoo.com/group/carrefourblinux/links/
Fiches EDU : http://blinuxwiki.pbwiki.com/FichesEdu
