On Mo, 2011-12-05 at 12:12 +0100, Chris Kühl wrote:
I plan to do this work in 3 steps:
1) The first step, which I've started, is to decouple the session and
server from each other and also modify objects that require both the
session and server objects as needed. Once this is done the server
should function as it does now and all tests should pass in order to
move on to step 2.
2) Move session into separate binary using a one-to-one dbus
connection for communicating between the 2 processes. At this stage
only one session is run at a time and all tests should pass as before.
I hate to interrupt your ongoing work, but can we reverse the steps so
that we first introduce the helper executable and a way to start it,
including the direct D-Bus communication with it?
I discovered end of last week that ActiveSync no longer works:
apparently fork without exec leaves the forked process in a state where
GIO gdbus is just blocking the caller without ever reaching activesyncd
over D-Bus. That confirms that fork+exec is indeed needed.
My plan is to use the helper binary as soon as possible for local sync.
Thus the desire to have it up and running rather sooner than later,
independent of refactoring the syncevo-dbus-server to use it.
You mentioned catching SIGCHILD. Please don't do that. It has the
disadvantage that there can be only one signal handler. Instead rely on
the specific connection to a helper process to detect premature exits.
My expectation is that this will be reported as a "peer has
disconnected" error at the D-Bus level (for open calls) resp. signal
(for watching the peer).
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.