DBus threading question

[Schmottlach, Glenn]

I'm trying to understand the "recommended" pattern for implementing a client application that is using a DBus service that provides both methods to call and asynchronously emits signals.

For the sake of argument, let's assume I choose to use either the GLib binding or C++ binding to DBus (I believe they're similar). For a client application, I was anticipating structuring it as follows.

The entry point to the client application (e.g. main()) is the primary thread that attaches to the bus (let's say the session bus). It creates a connection object referencing the remote service. After the connection object is created, a new (worker) thread is spawned (with the connection object passed to it) that will be used to make several synchronous calls to methods exposed by the remote service.

After the "worker" thread has been spawned, the main thread calls the "mainloop" function which won't return until the message dispatch loop is exited for some reason (perhaps the worker thread is commanded to exit by a signal from the remote service).

In this scenario, it seems the "main" thread is busy polling on the file descriptors for the transport looking for incoming messages. If they are signals we're interested in then the callbacks would be executed on the "main" thread (or dispatch loop).

While this is going on, the "worker" thread is making synchronous method calls that block until a specific reply is seen. If I understand it correctly, this "blocking" call is actually polling on the same transport file descriptor that the "main" thread is polling on as well. If an incoming message (like a signal) is detected here then it's thrown on a queue to be processed later (after the response we're looking for has arrived).

Is this what is really going on? How do both threads block on the same transport without interfering with one another (e.g. who gets the first chance to check for messages and handle it)? Perhaps I'm using the wrong pattern for implementing a client. Can someone describe the recommended solution to both listen for incoming subscribed signals and also make potentially synchronous calls at the same time. Would it be a "bad idea" to try to make calls to the remote service from a signal handler that's called on the "main" thread? In which thread should signals be ultimately handled - in the context of the signal handler (main thread) or somehow handled in the context of the worker thread?

Thanks for anyone who can shed some light on this topic...