On Wed, Dec 14, 2011 at 2:26 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mi, 2011-12-14 at 13:27 +0100, Chris Kühl wrote:
> On Tue, Dec 13, 2011 at 4:04 PM, Patrick Ohly <patrick.ohly(a)intel.com> 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.
One more thought about the various classes in the server and there
inter-dependencies: would it make sense to introduce signals+slots as a
way to connect the classes?
Boost.Signals would be the obvious candidate.
Well, that wouldn't work for what i was trying to do. I was attempting
to move the entire session along with it's dbus interface into the
helper binary. This was not going very well as the coupling was too
great. I'm now looking at doing the fork DBusTransportAgent similar
to how it's done in LocalTransportAgent but with the exec of course.
This looks more likely to work out and makes the helper leaner.
> > I discovered end of last week that ActiveSync no longer
> > 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.
It's the usage of GIO gdbus in activesyncd which is causing that, not
the GIO gdbus usage in SyncEvolution. activesyncd and its client
libraries switched unconditionally, so now SyncEvolution must adapt.