Pour chaque requête D-BUS, tu vas écrire dans la socket 2, puis le broker va copier le contenu de ta requête et l'écrire dans le socket 1, et pareil au retour pour la réponse.
Tu multiplie les read()/write()/select() dans tous les sens, et donc les appels système. C'est ça qui est chiant.
Avec un système où le serveur fait office de broker (usage typique d'un middleware), tu as ça:
Serveur <--- UNIX --> Client
Une seule paire de read()/write() et c'est parti. Tu divises les appels système par 2.
En terme de coût d'IPC, sur de l'embarqué, je pense que D-BUS est vraiment pas avantageux.
Certes, la notion de broker permet de faire plein de trucs délirants (pub/sub machin truc), mais ça n'a de sens que sur de Desktop où tu as pidgin, thunderbird, firefox, mpd et 150 autres processus utilisateur qui tournent.
[^] # Re: Comment ça marche ?
Posté par Gui13 (site web personnel) . En réponse à la dépêche A-Bus, un autre bus dédié GNU/Linux embarqué. Évalué à 9.
Je pense surtout qu'ils reprochent à DBUS d'utiliser 2 sockets UNIX pour communiquer d'un client à un serveur.
Typiquement, D-BUS c'est ça:
Pour chaque requête D-BUS, tu vas écrire dans la socket 2, puis le broker va copier le contenu de ta requête et l'écrire dans le socket 1, et pareil au retour pour la réponse.
Tu multiplie les
read()/write()/select()dans tous les sens, et donc les appels système. C'est ça qui est chiant.Avec un système où le serveur fait office de broker (usage typique d'un middleware), tu as ça:
Une seule paire de
read()/write()et c'est parti. Tu divises les appels système par 2.En terme de coût d'IPC, sur de l'embarqué, je pense que D-BUS est vraiment pas avantageux.
Certes, la notion de broker permet de faire plein de trucs délirants (pub/sub machin truc), mais ça n'a de sens que sur de Desktop où tu as pidgin, thunderbird, firefox, mpd et 150 autres processus utilisateur qui tournent.