2012/3/15 Patrick Ohly <[email protected]>:
> On Thu, 2012-03-15 at 15:43 +0100, Krzesimir Nowak wrote:
>> 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
>
> Is the logic of the if() check accidentally reverted here?
Looks like I need more sleep. Sorry. Fixed and testing again.
> void ForkExecChild::connect(bool delayed /* = false */)
>
> + if (delayed) {
> + m_conn = GDBusCXX::DBusConnectionPtr(dbus_get_bus_connection(address,
> +
> &dbusError));
> + } else {
> + m_conn =
> GDBusCXX::DBusConnectionPtr(dbus_get_bus_connection_delayed(address,
> +
> &dbusError));
> + }
>
>
> --
> 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
