_dbus_connection_acquire_io_path lock

[Havoc Pennington]

Hi,

On Wed, Nov 12, 2008 at 1:57 PM, jaikumar Ganesh <jaikumarg at gmail.com> wrote:
> a) What exactly does the io_path lock accomplish ? Can the code be safely
> reentrant ?

If two threads were reading or writing from the socket at once, it
would be undefined which bytes went to which thread. There has to be a
lock on the socket. As Thiago says it could theoretically have a
separate read and write lock, but it would be complicated and not all
that compatible with the way the current codebase works.

> b) I have seen mentions of DBusWatch and DBusTimeout to use in such cases.
>     Any pointers to some code samples ?

This is how you would connect to a main loop. There's a very basic
main loop in dbus-daemon, in the dbus source tree. Or look at the GLib
or Qt main loops, for example. Or use one of them.

> c) Any other work arounds ?

If you were using a main loop to read messages, then the wakeup main
function (set on DBusConnection) I think should be used to kick the
thread that is blocking in the main loop (by writing a byte to a pipe
it's selecting on), which would cause that thread to release the IO
lock thus enabling the write thread to write to the socket.

Whether this works or not at the moment, I don't know. It's not
something many people will have tested. But if you're blocking on both
a pipe and the dbus socket as with a main loop, then in theory there's
this pipe to be used to wake up the select().

If you don't have a main loop and are just blocking in
dbus_connection_pop_message() or something, then I don't think there's
much fix even in theory. It's just a conceptual deadlock to try to use
the socket from two threads at once, with no way to wake up the thread
blocking on read.

Havoc