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? 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. D-Bus is then responsible for calling the callback (which would otherwise be the lock signal handler), and there should be no race condition. Cheers, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
