Hi,

Simon McVittie wrote:
> (Also, the semantics of DBusConnection are that if you ever make a blocking
> method call on one thread, it takes a lock, and all API calls made by the
> other thread on the same connection will block waiting for the lock until the
> blocking method returns; this means you can't usefully make blocking calls on
> the same connection from two threads.)
> 

This is not supposed to be true... not to say there aren't bugs, since 
there's been little real testing of the threaded case (still). But locks 
should be dropped appropriately such that multiple threads can do 
blocking method calls at once.

Looking at this code just now, I can imagine that it isn't quite right - 
it looks like we might want to check in do_iteration after acquiring the 
IO path whether some other thread has already queued the message reply 
we might want, and it looks like we might want to wake all blocking 
threads when we release the IO path instead of just one. I'm not sure, I 
just looked at it quickly. But, it's supposed to work, is the larger 
point...

Havoc

_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus