On Sat, Feb 4, 2012 at 2:45 PM, Patrick Ohly <[email protected]> wrote: > On Sat, 2012-02-04 at 12:32 +0100, Chris Kühl wrote: >> One question I've got is when do we go about activating the sessions. >> I'm assuming this can be done immediately. The approach I'm taking now >> is to set the session 'active' and emit a status signal as soon as the >> helper session's up and ready. Thus, the server creates a session and >> it runs immediately. > > The 'active' state indicates that the session is allowed to be used for > operations. It doesn't guarantee that the session will react > immediately. So you could set it to active in the syncevo-dbus-server > side immediately, without waiting for the helper side to be ready. Is > that perhaps simpler? >
Yes, as soon as it's add/queued it'll be marked as active in the server process. >> I've also needed to look at how shutdown is handled in the course of >> this. From what I can tell there are 2 events that can cause a >> shutdown request: a signal or a file change. Because we are now >> dealing with the ideal case that we have no queued sessions & multiple >> sessions are running concurrently, > > You cannot guarantee that they are no queued sessions. A new session > might conflict with a running one and thus cannot start immediately. > Yeah, unfortunately things are not ideal. Have you given any further thought as to how we are going to properly detect conflicting sync sessions? This points getting close that this is going to need to be dealt with. I've not looked into this at length yet. Is there no interface I could use to test that syncs will not conflict? >> it doesn't seem to me that we need >> a ShutdownSession any longer. The shutdown session seemed to be used >> to get to the head of the queue and prevent any new sessions from >> starting. I'm going about removing that and just using the >> m_shutdownRequested flag to disallow starting any additional sessions >> etc. > > Do whatever works :-) The goal has to be that queued sessions are > discarded as soon as possible instead of delaying the shutdown. > > One open question is whether the syncevo-dbus-server should be allowed > to quit while there is a running sync. In the past it wasn't, because > *itself* was running the sync. Now I think the sync should continue to > run unless it was canceled explicitly itself. For example, if the > syncevo-dbus-server crashes for some reason, it would be nice to > complete the running sync instead of aborting it prematurely. > Ok, I've gone the route of ripping the shutdownSession out and enabling the sync to run even when the server shuts down. This actually results in a decent amount of code being removed in my yet-to-be-tested commit. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
