On Tue, Dec 13, 2011 at 4:04 PM, Patrick Ohly <[email protected]> wrote: > 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? >
Ok, I'm looking into this. The original plan was that Step 1 was a dependency of Step 2 but I've been reconsidering my approach. I'll look into what you're asking and get back to you soon. > 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. > If this is only happening with this combination, maybe it should be disallowed for a very brief time until this is sorted. > 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). > Yes, there is a closed signal for GDBusConnections. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
