DBus threading question

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20081211/da1d7877/attachment.pgp