Ich fange an, D-Bus als IPC Mechanismus für ein neues Projekt in Linux/KDE zu verwenden. Und ich habe entdeckt, dass die Dokumentation überhaupt nicht auf Nebenläufigkeit eingeht. Wie sollen D-Bus-Dienste mit mehreren gleichzeitigen Anrufen von verschiedenen Clients umgehen? Was ist das Threading-Modell? Kann ein Dienst davon ausgehen, dass es Single-Threaded ist und D-Bus Anfragen eigenständig in die Warteschlange stellt?D-Bus Threading Modell
Als Protokoll adressiert D-Bus Threading nicht.
D-Bus-Verbindungen empfangen die Nachricht seriell. Auf der Protokollebene sind die Antworten auf die Nachricht asynchron: d. H. Der Absender muss nicht auf Antworten warten, bevor er weitere Nachrichten sendet.
Während eine D-Bus-Implementierung im Prinzip Nachrichten gleichzeitig an Service-Implementierungen senden könnte, weiß ich nicht, dass dies der Fall ist. Normalerweise ermöglicht eine D-Bus-Implementierung (oder "binding", wenn Sie so wollen) dem Dienst, für jede Methode (oder sogar für jeden Methodenaufruf) zu entscheiden, ob er auf eingehende Methodenaufrufe synchron oder asynchron reagiert. Die Details dazu hängen von der jeweiligen Implementierung ab, die Sie verwenden.
Wenn Sie auf Methodenaufrufe asynchron reagieren, ist Ihre Service-Implementierung dafür verantwortlich, sicherzustellen, dass jeder Status konsistent bleibt, während mehrere Antworten ausstehen. Wenn Sie immer synchron antworten, wissen Sie, dass Sie immer nur mit einem Methodenaufruf zu tun haben.
Danke. Dies stimmt mit dem überein, was ich in Kubuntu mit der Qt-Bindung gesehen habe. Wenn ich in meiner Remotedienstmethode (Steckplatz) einen Haltepunkt festlegte und wenn es dann von zwei Clients aufruft, wurde der zweite Client vollständig blockiert, bis mein Code die erste Nachricht verarbeitet hatte. Aber ich war mir nicht sicher, ob ich mich darauf verlassen konnte. –