[PATCHES] D-Bus C++ binding fixes

[P. Durante]

Hi!

On Dec 28, 2007 5:07 PM, Olivier Hochreutiner
<olivier.hochreutiner at gmail.com> wrote:
> Hi there,
>
> After several tests on D-Bus C++ binding I found several bugs, and I
> made fixes for some of them.
> So here is what I found:
>
>
> 1. When a proxy is instantiated several times for a given connection,
> only one instance receive signals. Patch:
> fix-signals-multiple-proxies.patch
>
> ***
>
> 2. When two processes (both connected to the same bus) have an adaptor
> for the same object path and interface, when a method call is done on
> one of them, it is also done on the other one. For instance if you
> have two 'echo-server' running (supposing they have different bus
> names) and you call the method Hello of
> org.freedesktop.DBus.Example.Echo on one of them (with e.g.
> dbus-send), the method will also be called on the other one. Patch:
> fix-method-call.patch
>
> ***
>
> 3. Threading in libdbus-c++ is never compiled due to incorrect #ifdefs
> and an invalid type. Patch: pthread.patch
>
> ***
>

thanks a LOT, I've been very busy and things have rotten a bit lately
(and the queue of unreviewed patches has grown too, unfortunately)

> 4. Even after applying patch (3), having multiple threads is not
> working correctly. The problem can be easily reproduced with the
> 'echo-client-mt' example of D-Bus C++ binding. For recall this program
> creates 16 threads. Each thread does the same method call 100 times in
> a loop (method calls are done with
> dbus_connection_send_with_reply_and_block()), and the main thread is
> the dispatcher thread. When echo-client-mt is run, two things can
> occur:
>
> (1) It crashes with an out-of-memory error (that is, an exception is
> raised because dbus_connection_send_with_reply_and_block() returns an
> OOM error). I will explain this issue in another post because I
> believe the problem is in libdbus-1, not libdbus-c++.
>
> or
>
> (2) One of the threads hangs in poll() waiting for the method reply
> (see bt-thread-poll.txt), while the other threads are waiting to
> acquire the io path mutex (see bt-wait-io.txt). The dispatcher thread
> is usually also waiting in poll() (see bt-dispatcher-poll.txt), but it
> sometimes happens that it is waiting for the io path mutex.
> In this situation when the poll timeout is reached the program
> continues normally until it hangs again, or crashes as in situation
> (1).
> I believe this problem is caused by the fact that two threads (namely
> the dispatcher thread and one of the method-calling threads) poll the
> same fd at the same time. The method-calling thread owns the io path
> mutex while poll()'ing, but the dispatcher thread doesn't (it calls
> poll() on the fd without locking anything). Sometimes the
> method-calling thread returns from poll() before the dispatcher
> thread, and it goes as expected, but sometimes the dispatcher thread
> is notified first, resulting in the method-calling thread having to
> wait until poll times out, and only then it returns from
> dbus_connection_send_with_reply_and_block(). Of course all the other
> threads have to wait for the io path mutex.
> A workaround for this issue could be to make the dispatcher thread
> leave poll() before calling
> dbus_connection_send_with_reply_and_block() or
> dbus_bus_{add,remove}_match(). I guess this can be done by creating a
> pipe, adding its read fd to the list of fds the dispatcher polls, and
> writing something to the pipe's write fd before calling the
> above-mentionned functions. Probably a mutex or a condition variable
> would be needed too, to tell the dispatcher when the method call is
> finished.
> Is this solution acceptable ? Should the issue rather be fixed somehow
> in libdbus-1 ? What do you think ?
>
> ***

this race condition is unfortunately known, I think I wrote a patch
for that which got lost together with my old tree, I can't comment on
your fix right now before I dwell into the code again

>
> Beside these issues there are two things that I would like to ask:
>
> - I think D-Bus C++ sources should be moved out of Wengo's SVN. I
> believe it was already discussed on this list that it can be moved to
> git.freedesktop.org, using
> http://www.kernel.org/pub/software/scm/git/docs/git-svnimport.html. Is
> it still planned ?
>
they actually have been there for a while already, for some strange
reason gitweb doesn't show it but the tree is now at

git clone git://anongit.freedesktop.org/git/dbus/dbus-c++/

> - What about relicensing D-Bus C++ with the same license as dbus-1
> (i.e. MIT/X11) ?
>
I don't see any problem with that

> Well I think that's all. Merry Christmas and Happy New Year to everybody.
>
> Olivier Hochreutiner
>

happy new year to you too and thanks again,
Paolo Durante

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