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?
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
