<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> 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().<o:p></o:p> <o:p> </o:p> 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?<o:p></o:p> <o:p> </o:p> 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?<o:p></o:p> <o:p> </o:p>  <o:p></o:p> <o:p> </o:p> </div> </body> </html>