Blocking behavior on synchronous proxy method when called from synchronous adaptor method?

[mgruhler]

Hi everybody,

I've got a, probably more academic, question:
Given that I have an application with

1. one Adaptor (A) providing a synchronous method (M1) to be called, and
2. one Proxy (P) connected to another D-Bus participant, which
3. share the connection (i.e. have a single connection running a single event loop)

Is the behavior well-defined and will it work if:
within the implementation of M1, a synchronous method (M2) on P is called? (So: D-Feet->M1->M2)

Or will/could this lead to a behavior where the connection will only service M2s return value until M1 has been completed, which will obviously not be the case?

I've tried to write some example code for this, as this is something I've stumbled upon in one of my applications, which leads to the application being stalled. However, with the example code I've got somewhat erratic behavior, from working fine to long delays in Proxy method returns, though no real deadlocks.

Am I missing something? Have I not grasped the concept of how sdbus works with connections during synchronous method calls?

Thanks for any insights

[sangelovic]

Hi. This use case is a valid one and yes it shall work as you logically expect. Synchronously calling M2 on P while servicing the M1 call simply blocks the A (and P, too) from processing further incoming D-Bus messages. These are being enqueued, waiting until the M2 call -- and, subsequently, M1 call -- has finished. And, naturally, M1 won't finish until M2 has finished. M2 is a blocking call (given that I understand your situation correctly), thus blocks the M1 and M1 routing can only continue after M2 has finished.

Exactly such a use case is shown to work in sdbus-c++ stress tests: https://github.com/Kistler-Group/sdbus-cpp/blob/master/tests/stresstests/sdbus-c%2B%2B-stress-tests.cpp#L169

Hope this helps.