Estoy empezando a usar D-Bus como mecanismo de IPC para un nuevo proyecto en Linux/KDE. Y descubrí que la documentación realmente no aborda la concurrencia en absoluto. ¿Cómo se espera que los servicios de D-Bus traten las múltiples llamadas simultáneas provenientes de diferentes clientes? ¿Cuál es el modelo de roscado? ¿Puede un servicio asumir que es de subproceso único y D-Bus pondrá en cola las solicitudes por sí mismo?D-Bus threading model
Como protocolo, D-Bus no aborda el enhebrado.
Las conexiones D-Bus reciben un mensaje en serie. En el nivel de protocolo, las respuestas al mensaje son asincrónicas: es decir, el remitente no tiene que esperar las respuestas antes de enviar más mensajes.
Si bien, en principio, una implementación de D-Bus podría enviar mensajes a implementaciones de servicio al mismo tiempo, no conozco ninguno que haga esto.
Normalmente, una implementación de D-Bus (o "vinculante", si se quiere) permite que el servicio decida por cada método (o incluso por cada método) si responde a las llamadas al método entrante de forma síncrona o asíncrona. Los detalles de esto dependen de la implementación particular que esté utilizando.
Si responde a las llamadas a métodos de forma asincrónica, la implementación de su servicio es responsable de asegurarse de que cualquier estado se mantenga constante mientras hay varias respuestas pendientes. Si siempre responde sincrónicamente, sabrá que solo está tratando con una llamada de método a la vez.
Gracias. Esto es consistente con lo que vi en Kubuntu usando el enlace Qt. Si establecía un punto de interrupción en mi método de servicio remoto (ranura) y luego lo llamaba desde dos clientes, el segundo cliente estaba completamente bloqueado hasta que mi código había terminado de procesar el primer mensaje. Pero no estaba seguro si podía confiar en esto. –