Je commence à utiliser D-Bus comme mécanisme IPC pour un nouveau projet sous Linux/KDE. Et j'ai découvert que la documentation ne traite pas du tout de la concurrence. Comment les services D-Bus doivent-ils traiter plusieurs appels simultanés provenant de différents clients? Quel est le modèle de threading? Un service peut-il supposer qu'il est mono-threadé et D-Bus mettra en file d'attente les demandes par lui-même?Modèle de filetage D-Bus
En tant que protocole, D-Bus n'adresse pas le thread.
Les connexions D-Bus reçoivent un message en série. Au niveau du protocole, les réponses au message sont asynchrones: c'est-à-dire que l'expéditeur n'a pas à attendre les réponses avant d'envoyer plus de messages.
Bien qu'en principe une implémentation D-Bus puisse envoyer simultanément des messages à des implémentations de service, je ne connais personne qui le fasse. En règle générale, une implémentation D-Bus (ou "binding", si vous voulez) permet au service de décider pour chaque méthode (ou même pour chaque appel de méthode) de répondre aux appels de méthode entrants de manière synchrone ou asynchrone. Les détails de ceci sont à la mise en œuvre particulière que vous utilisez.
Si vous répondez aux appels de méthode de manière asynchrone, votre implémentation de service est responsable de s'assurer que tout état est maintenu cohérent alors que plusieurs réponses sont en attente. Si vous répondez toujours de manière synchrone, vous savez que vous ne traitez qu'un seul appel de méthode à la fois.
Merci. Ceci est cohérent avec ce que j'ai vu dans Kubuntu en utilisant la liaison Qt. Si je définissais un point d'arrêt dans ma méthode de service à distance (emplacement) et que je l'appelais ensuite à partir de deux clients, le deuxième client était complètement bloqué jusqu'à ce que mon code ait fini de traiter le premier message. Mais je n'étais pas sûr de pouvoir compter sur ça. –