DBus threading question
glenn.schmottlach at harman.com
Thu Dec 11 12:43:05 PST 2008
So for those "uninteresting" messages that the worker thread queues while it's waiting for a specific reply, who ends up dispatching those . . . the "main" dispatch loop?
Also, since the worker thread locks out the signal dispatch (main) thread while it's waiting for a reply, would it be advantageous to have each thread own its own connection object so there would be no contention on the lock? In this case, would the DBus library actually allow you to create two truly separate connection objects even though they're connecting to the same service (e.g. does it try to share the connection objects)?
From: dbus-bounces at lists.freedesktop.org [mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Thiago Macieira
Sent: Thursday, December 11, 2008 3:17 PM
To: dbus at lists.freedesktop.org
Subject: Re: DBus threading question
Schmottlach, Glenn wrote:
>Here's where the questions related to concurrency and thread-safety
>enter the picture. The worker thread loops (until the gQuit flag is set)
>and continuously makes synchronous (blocking) calls to toggle the play
>state of the media player. Based on my (limited) understanding of the
>logic, a synchronous method call causes the thread to poll/select on a
>socket descriptor waiting for a specific reply. If any signals (or
>unrecognized replies) arrive during this process they're placed on a
>queue to be process later. So this seems to imply that when the
>synchronous call is made from the worker thread, the "main" thread that
>called dispatcher.enter() is also polling/selecting on the same socket
>descriptor at the same time. This means that when a message does arrive
>both threads (the "main" and worker thread) are each vying to dispatch
>the message. Is this the correct interpretation of what is going on
>internally? How is the message handling arbitrated? What happens if the
>"main" thread retrieves the expected reply message that the worker
>thread is waiting on?
A blocking call keeps the transport locked for the entire duration of the
process. That means no other thread can dispatch that connection while the
blocking call is in progress. The blocking call function will keep the
lock until it receives the reply it wants, or until a timeout happens.
Meanwhile, if any messages are received which are uninteresting for it,
the function queue them up for dispatching later -- for another function.
1) there's no race condition like you describe, because the worker thread
has the priority
2) if the worker thread takes too long to finish (like a call without a
reply -- takes 25 seconds), everything else is blocked.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
More information about the dbus