Re: [SyncEvolution] DBus server rework: sync, shutdown, and password request
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.