W dniu 15 marca 2012 10:58 użytkownik Krzesimir Nowak <[email protected]> napisał: > 2012/3/15 Patrick Ohly <[email protected]>: >> On Thu, 2012-03-15 at 10:21 +0100, Krzesimir Nowak wrote: >>> W dniu 14 marca 2012 15:30 użytkownik Patrick Ohly >>> <[email protected]> napisał: >>> > Hello Krzesimir! >>> > >>> > You added the add/remove_filter() methods to DBusConnectionPtr, with the >>> > comment "those additions will be needed for ForkExec ready message >>> > handling" in the commit message. >>> > >>> > The methods themselves are not documented. Can you explain a bit how >>> > this is meant to work? >>> >>> The history is that I needed to add a new signal to ForkExec, because >>> activation of DBus interface on child side was racing with using this >>> interface on parent side. >> >> Wouldn't it be easier to delay message processing on the child side >> until the child is set up, then enable the message processing? >> >> http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusConnectionFlags >> mentions G_DBUS_CONNECTION_FLAGS_DELAY_MESSAGE_PROCESSING and >> g_dbus_connection_start_message_processing() for this purpose. >> >> Then the parent can start making method calls right away. They simply >> will not be processed before the child is really ready to handle them. > > I have not noticed that before - I will check it.
Nope, still racy. I tested that by running a loop with 100 iterations of TestDBusServerPresence and breaking it after first failure. It got me as far as 34 iterations. Usually first 15-20 iteration succeeded. Failures on 1 iteration weren't all that rare. I have created two quick-and-dirty branches with my two attempts to solve the problem with g_dbus_connection_start_message_processing(): 1. with running said function directly: https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/css-with-direct-msg-proc 2. with running said function in idle callback: https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/css-with-idle-msg-proc My solution (ready signal) completed the loop successfully. Of course, I hope I got your hints right. The loop I used: for i in `seq 1 100`; do ../../syncevolution/test/test-dbus.py -v TestDBusServerPresence; if test $? -ne 0; then echo "Fail at $i"; break; fi; done >> >> -- >> Best Regards, Patrick Ohly >> >> The content of this message is my personal opinion only and although >> I am an employee of Intel, the statements I make here in no way >> represent Intel's position on the issue, nor am I authorized to speak >> on behalf of Intel on this matter. >> >> _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
