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