On Mon, Jan 23, 2012 at 12:55 PM, Chris Kühl <blixtra(a)gmail.com> wrote:
On Sat, Jan 21, 2012 at 9:23 PM, Patrick Ohly
> On Fr, 2012-01-20 at 21:21 +0100, Patrick Ohly wrote:
>> On Fr, 2012-01-20 at 10:53 +0100, Chris Kühl wrote:
>> > On Thu, Jan 19, 2012 at 4:19 PM, Patrick Ohly <patrick.ohly(a)intel.com>
>> > > On Mi, 2012-01-18 at 16:55 +0100, Chris Kühl wrote:
>> > >> I've renamed my branch to concurrent-sync-sessions and rebased
>> > >> master. I'm now going through and making required changes to
>> > >> to work.
>> > >
>> > > Note that I pushed another change onto a new
>> > > This affects you because syncevo-dbus-server will have to relay
>> > > suspend/abort requests. The helper process will have to deal with
>> > > signals similar to syncevo-local-sync helper in that branch.
>> > >
>> > > Do these changes make sense?
>> > >
>> > Yes, this looks fine.
>> They are on their way towards master. Running one more test now.
>> After looking into what it would take to have all backends react to
>> abort requests in a timely manner I have come to the conclusion that it
>> will be much simpler to just let the process running them die when
>> receiving a signal. Teaching libs with a synchronous API, like libneon
>> and the activesyncd client libraries, how to watch additional events
>> will be hard.
>> For syncevo-local-sync I have implemented that and intend to merge it
>> soon, see for-master/signal-handling branch.
>> Another patch modifies the syncevo-dbus-server. It's a step towards
>> gettting rid of SyncContext::checkForAbort/Suspend(). This is not
>> absolutely necessary at the moment and probably conflicts with your
>> server rewrite, so I intend to keep it on a branch for now.
> After looking at the only regression reported by testing for the
> for-master/fork-local-sync branch it turned out that this final patch
> *is* needed: when not applied, TestLocalSync.testConcurrency fails
> because the Session.Abort() call has no effect while the local transport
> still waits for the child to start. session.cpp sets the SYNC_ABORT
> status and quits the main loop with the goal getting the SyncContext to
> react to the abort. Instead the fork/exec local transport restarts the
> loop and the sync session starts normally.
> This is partly a failure in the local transport (it would have to do a
> checkForAbort()), partly in the session (as mentioned in the commit
> message for my latest commit, it allowed a session to go from "aborted"
> to "running").
> Either way, with the latest commit applied, the transport gets canceled
> as soon as Abort() is called and the session aborts as intended.
> Chris, I hope I'm not disrupting your work too much by merging the
> entire "signal-handling" into master.
No please go ahead and merge. This fixes I was seeing on the horizon
anyway. I'd also rather have any fixes and changes you've made early
rather than later.
Also, I was reminded by the TestDBusServerTerm.testTermConnection test
that I still needed to implement the Connection interface in the
helper. I've pushed some code to that end although I'm still working
out some kinks in the dbus communication between the server and helper
at the moment.
This was done yesterday (or 2 days ago now). It my be good to give a
little more detailed update at this point.
The last couple days I've been fixing various issues when running
test-dbus.py. Quickly I found that there was an issue in how the
session's dbus interface was being initialized. The interface was not
immediately available after Session.StartSessionWithFlags returned.
This was because the interface was not being made available until the
onConnect callback was invoked. I've now changed this to spawn the
helper then wait for the helper to indicate that its DBus interface is
ready to be used. Included in this change is a move of all the
ForkExec code in Session and Connection out of the constructors and
into an init() method.
In order to provide the helper binary with additional information I've
created an addEnvVar(name, value) method to the ForkExecParent which
obviously adds an environment variable. I'm using this to indicate
whether the helper should start the Session or Connection DBus
With the above changes, the initialization of and communication with
the helper binary seems to work well. I'm continuing to work my way
through the tests. Right now I'm dealing with getting autosync to work
properly. This is requiring some additional communication between the
helper and server binaries as well as reworking some code I changed
when removing the priority queues in the server.
On the more distant horizon is reworking logging to use syslog in the
server binary and providing adequate debugging in the helper binary.
The other items on your initial list should be worked out while going
through the tests.