DBus threading question
thiago at kde.org
Thu Dec 11 04:38:24 PST 2008
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
(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
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
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20081211/da1d7877/attachment.pgp
More information about the dbus