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