Re: [SyncEvolution] GDBus C++ add_filter + fork/exec dbus-server
W dniu 15 marca 2012 10:58 użytkownik Krzesimir Nowak
<qdlacz(a)gmail.com> napisał:
2012/3/15 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Thu, 2012-03-15 at 10:21 +0100, Krzesimir Nowak wrote:
>> W dniu 14 marca 2012 15:30 użytkownik Patrick Ohly
>> <patrick.ohly(a)intel.com> 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#GDBusConnect...
> 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-syncevolut...
2. with running said function in idle callback:
https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolut...
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.
>
>