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