DBus threading question

[Schmottlach, Glenn]

Thanks for the insights Thiago. It's still, however, a bit fuzzy for me. Have you run across any threading recommendations for DBus that were either captured in the archives are documented elsewhere? It seems like a pretty important topic that someone might've addressed at some point in a tutorial or something. In particular, I'm interested in the correct approaches to take with the several binding to DBus that are available (in particular the C++ or Glib binding).

Thanks . . .

-----Original Message-----
From: dbus-bounces at lists.freedesktop.org [mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Thiago Macieira
Sent: Thursday, December 11, 2008 7:38 AM
To: dbus at lists.freedesktop.org
Subject: Re: DBus threading question

On Thursday 11 December 2008 13:18:49 Schmottlach, Glenn wrote:
> If I recall correctly, the bindings that I mention (GLib and C++) do in
> fact use poll() to check for activity on the incoming descriptor. Still,
> are there any issues with both threads "polling" (via select or poll) on
> the same socket descriptor. I guess I have to assume the poll/select
> implementation will do the appropriate locking to guarantee only a single
> thread polls at any one time. Is this correct or am I missing something?

It doesn't matter how many threads are selecting or polling a file descriptor. 
The actual I/O operation (reading and writing) is what needs to be protected.

dbus_connection_* functions already do that and lock the transport to prevent 
such concurrent access. You don't need extra locking around it: DBusConnection 
is considered to be thread-safe.

What you have to be careful, though, is that DBusConnection callbacks can 
happen in any thread. That means that, if you use 
dbus_connection_send_with_reply_and_block, DBusConnection will create and 
destroy a DBusTimeout via callbacks in the thread you called. So, you have to 
be careful in your callbacks to not access any mainloop global data that isn't 
protected.

(That gave me a lot of headache with the QtDBus mainloop, because timers and 
file-descriptor watches can only be touched from the thread that they were 
created on)

The same is true for dbus_connection_dispatch() and the signal filter and 
object vtable callbacks.

> Also, is it safe to call methods on the server from a signal handler which
> is invoked from the thread calling the mainloop (e.g. the "main" thread in
> my example)? In general, is it better to make method calls in one thread
> and receive signals in another? Is that the accepted pattern?

Do not reenter libdbus-1 on the same DBusConnection code from the same thread. 
That might cause a deadlock.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Software Engineer - Nokia, Qt Software
  Qt Software is hiring - ask me
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358