On Wed, Sep 16, 2009 at 7:12 PM, Iustin Pop <[email protected]> wrote: > 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. >
Yeah, we tried to have locks not spread all over the place, to make sure they were more verifiable! :) Plus, it made it easier with the try: finally: constructs needed for locking! :) Guido
