A libev based mainloop and lost signals

[Thomas Themel]

Hi,

following up on an earlier discussion on this list of how to have the
outsource DBus handling to a thread while retaining the ability to emit
signals from other threads, I implemented a simple libev based main loop
that seems to do this for me most of the time.

It uses libev to handle the i/o monitoring, and whenever a watch is triggered,
I call dbus_handle_watch on it and then loop to dispatch all messages while
the dispatch status is DATA_REMAINS.

While this seemed to work well initially, I've recently run into problems with
lost signals on clients - my DBUS_VERBOSE=1 logs show that the client receives
the signal, but it never seems to arrive in the message handler function.

My client code uses dbus_connection_send_with_reply_and_block to do method
calls on the server while the mainloop runs in another thread, is this a good
idea? There is a line in the docs that makes me suspect it's not, but I couldn't
quite figure out how to apply it to my situation:

| This function does not reenter the main loop, i.e. messages other than the
| reply are queued up but not processed.

I suspect it has to do with my problem, but since the main loop is running in a
different thread, I initially thought this wouldn't apply here. If that is my
problem, is there anything less desperate for me to do than implementing this
"block for message reply" stuff again in my own library? 

A stripped-down version of the code I'm using, which is basically an
implementation of the Properties interface with a custom PropertyChanged event
(I came up with it before the recent spec additions) is at
<http://www.themel.com/oid-store-0.0.1.tar.gz>. What I do is send a Set call
from a client who is also subscribed to the PropertyChanged signal that is
emitted on the server when processing this Set. While the Set call always
succeeds, the event is not reliably dispatched in the client code. It doesn't
seem to have anything to do with the order of messages on the DBus, (which
should be constant anyway, since the server emits the signal strictly before
sending the method reply) since I have seen both outcomes on the client with
identical dbus_monitor output.

A timinig issue seems to be involved, since it's much easier to trigger with
plain running or DBUS_VERBOSE=1 redirected to a file than with DBUS_VERBOSE=1
to console or strace. 

I'd be thankful for any advice. I have output from DBUS_VERBOSE=1 for a good
run at <http://www.themel.com/dbus-good.log> and for one that crashed at
<http://www.themel.com/dbus-bad.log>, maybe someone can get more information
from it than I do.

ciao,
-- 
[*Thomas  Themel*]      'To a hardcore geek, "Open" and "Source" are like
[extended contact]   the nipples on the breasts of Jennifer Love Hewitt.'
[info provided in]              - Mr. Cranky reviewing "Antitrust"
[*message header*]   <URL:http://www.mrcranky.com/movies/antitrust.html>