On Wed, Sep 16, 2009 at 06:59:26PM +0100, Guido Trotter wrote: > > On Wed, Sep 16, 2009 at 5:29 PM, Iustin Pop <[email protected]> wrote: > > > > On Wed, Sep 16, 2009 at 06:10:20PM +0200, Michael Hanselmann wrote: > >> Also increase the table of contents' depth to 4. > > > > Why? Doesn't this make the TOC too big? > > > >> +Non-blocking lock acquiring > >> +^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> + > >> +Acquiring locks for OpCode execution is always done in blocking mode. They > >> +won't return until the lock has successfully been acquired (or an error > >> +occurred, although we won't cover that case here). > >> + > >> +``SharedLock`` and ``LockSet`` must be able to be acquired in a > >> +non-blocking way. They must support a timeout and abort trying to acquire > >> +the lock(s) after the specified amount of time. > > > > Uh, this also means that all callers must deal with this. Shouldn't just the > > implementation of these two change so that they don't block, but internally > > retry? > > > > Currently we're holding locking brainstorms over here. :) (and we're > still at sharedlock stage) > Definitely for sharedlock we need the caller to handle the condition > (for example lockset does need to release the other locks if an > acquire fails, and such, or we don't solve the problem at the root of > this). Possibly we can hide it in LockSet, for now :)
One alternative is that, instead of the staged acquire in mpcu, we do a single acquire. This might not work because we don't know all the locks needed for an instance before we lock it. Hmm… But, in any case, I realised that the only significant user of locking.py is actually mcpu.py, and only in a single place (right?), so even not hiding it is fine. iustin
