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> wrote:
> > On Mi, 2012-01-18 at 16:55 +0100, Chris Kühl wrote:
> >> I've renamed my branch to concurrent-sync-sessions and rebased onto
> >> master. I'm now going through and making required changes to get tests
> >> to work.
> > Note that I pushed another change onto a new "signal-handling"
> > 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"
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.
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.