Blocking behavior of synchronous calls

[Schmottlach, Glenn]

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
loop?

 

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...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20081121/9706e5c6/attachment.htm