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? > 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. > 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. > Now for the actual infoRequest I'm doing the following. When the > request is made the helper emits a password request signal and waits. > The helper only does one job, so this is fine. The SessionResource in > the server receives this signal and creates an InfoRequest. Now we > can't wait in the server process because we've got possibly multiple > concurrent sessions running. So, I've introduced signal in InfoReq > that lets us know when the response is received. This signal is > connected to a routine in the SessionResource which passes the result > to the session helper who can now carry on its business. Sounds reasonable. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
