Blocking behavior of synchronous calls

Schmottlach, Glenn GSchmott at
Fri Nov 21 07:53:01 PST 2008

I have been studying the DBus implementation trying to gain a deeper
understanding of the control flow through the library. In particular, it
appears that the Glib binding implements synchronous calls (with
timeouts) to remote services via dbus_connection_send_with_reply() and
then blocks on dbus_pending_call_block().


The comments in the code seem to indicate that dbus_pending_call_block()
does not re-enter the mainloop or process other messages. If this is
true, how does the message loop continue to process incoming signals and
responses? Does the DBus library own a dedicated thread (e.g. mainloop)
that polls/selects the transport file descriptors looking for incoming
messages (and optionally) sending out-going messages if they're queued
up? While a user's code is blocked on dbus_pending_call_block() can the
DBus library still receive signals and dispatch them to registered
callbacks? If that's possible, what would happen if a signal handler
made a blocking call to a remote service? Would that block this main


I suspect my mental picture of this is all wrong. I guess if the DBus
had its own thread to run the main loop there wouldn't be so many
bindings that provide a main loop. It appears that DBus is indeed
thread-safe (I see locking/unlocking going on all over the place) but
it's not clear to me who owns the thread. Basically, when user code
blocks on a synchronous call, is the main loop really blocked?




-------------- next part --------------
An HTML attachment was scrubbed...

More information about the dbus mailing list