dbus_pending_call_set_notify race

[Havoc Pennington]

Alexander Larsson wrote:
> On Thu, 2006-11-30 at 18:24 +0100, Alexander Larsson wrote:
>> On Thu, 2006-11-30 at 12:00 -0500, Havoc Pennington wrote:
>>
>>> Of course this is pretty inconvenient. Maybe instead of the idle 
>>> handler, we could offer a function that essentially did the above - "set 
>>> notify or return reply" - but even with that convenience function it's 
>>> annoying, since your notifier will be run in the main loop thread and 
>>> your set_notify_or_get_reply is in a different thread, and it's probably 
>>> a pain to code things in two ways so you can handle the reply in either 
>>> thread.
>> Yeah, the best thing would be handling it internally in dbus with an
>> idle.
> 
> I hit this race in the wild today (I have a main loop thread and a
> worker thread sent an async message). Is anyone working on a fix for
> this? I can't figure out a workaround for it, and it makes threading
> dbus apps quite unsafe. 
> 

Nobody working on it that I know of (dbus could use some maintenance 
help, though on the other hand I'm happy there isn't much feature creep...)

Havoc