On Thu, 2009-08-27 at 17:45 +0100, Frederik Elwert wrote: > Am Donnerstag, den 27.08.2009, 16:58 +0200 schrieb Patrick Ohly: > > On Thu, 2009-08-27 at 12:05 +0100, Jussi Kukkonen wrote: > > > contains > > > read-only methods that can be called without a lock and a StartSession > > > call, which is used when a client wants a lock. StartSession returns a > > > object path for SyncSession, which has a signal to tell when the lock is > > > acquired. So there may exist multiple sessions, but only one has a lock. > > > The SyncSession contains also the read+write methods. > > > > Client's need to be aware of a race condition: > > 1. StartSession returns object > > 2. server locks the session, firing the signal > > 3. client receives object, starts to watch for the signal > > => client waits forever > > > > So the clients have to watch for the signal and before going to sleep, > > check whether they already have the lock. > > Just one question to help me understand: Why would I need the object > path until the session is locked?
If the client finds that it no longer needs the lock, it can call a method on that object to cancel it. Hmm, do we really need this in practice? It is part of the Connect interface, and for a good reason in that case. For the GUI it might be overkill. > Couldn’t one make StartSession return > the object path just when the lock is acquired? Then it would of course > make sense to call this method asynchronous, at least for GUI clients. We could add a parameter to StartSession which let's the client choose whether he wants the object returned immediate in the "unlocked" state or whether he wants to block. -- 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
