DBus threading question

[P. Durante]

On Thu, Dec 11, 2008 at 9:43 PM, Schmottlach, Glenn
<glenn.schmottlach at harman.com> wrote:
> 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)?
>
the library does try to reuse the same connection objects unless they
are created as private connections (with
dbus_connection_open_private())

> -----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 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.
>
> Conclusions:
>
> 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
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>