On Mon, 2007-10-22 at 12:10 -0700, Mark Spiegel wrote:
> Thanks Dan.  How about the second part.  Should the PENDING_LOCK be 
> taken en route from the SHARD_LOCK to EXCLUSIVE_LOCK?  Which is right, 
> the code or the function header?

Doesn't really matter as far as I know. Which I guess means 
the code is correct.

Dan.


> Dan Kennedy wrote:
> > On Mon, 2007-10-22 at 10:56 -0700, Mark Spiegel wrote:
> >   
> >> I posted this to the list last Wednesday and haven't seen a reply.  
> >> D0n't want to create traffic in the defect database if I am in error.  
> >> Anyone want to take a crack at this?
> >>
> >> While working on a VFS for use in 3.5.1, I was looking at the winLock() 
> >> and have a question. 
> >>
> >> Is it possible for the lock on a winFile object to progress from 
> >> SHARED_LOCK to EXCLUSIVE_LOCK without first acquiring a RESERVED_LOCK?
> >>     
> >
> > In one case.
> >
> > After first obtaining a shared-lock on the database file, SQLite checks
> > for a hot-journal in the file system. If there is such a journal, it
> > tries to obtain the EXCLUSIVE lock so that it can do the rollback
> > operation. If it fails to get the exclusive lock, the pager layer
> > immediately drops any shared lock that is held and returns SQLITE_BUSY
> > to the caller. The assumption being that some other connection is
> > rolling back the hot-journal.
> >
> > So I think you are right that there is a race condition, but it is
> > a benign one. 
> >
> > Dan.
> >
> >   
> >> Assuming that it is, it seems that the comments at the start of the 
> >> function are at odds with the implementation a little bit.  The comments 
> >> indicate that a PENDING_LOCK will be an intermediate state between a 
> >> SHARED_LOCK and EXCLUSIVE_LOCK.  This would make sense based on the 
> >> other SQLITE docs I've read.  However, as I read the code it would seem 
> >> that a SHARED_LOCK is not acquired if proceeding from a SHARED_LOCK to 
> >> EXCLUSIVE_LOCK.  The PENDING_LOCK is only acquired if the current lock 
> >> type is NO_LOCK or the current lock type is RESERVED_LOCK and an 
> >> EXCLUSIVE_LOCK is desired.
> >>
> >> The reason I'm asking is that later in the function where the 
> >> EXCLUSIVE_LOCK is acquired, the SHARED_LOCK is released before trying to 
> >> acquire the EXCLUSIVE_LOCK.  Without the protection of the PENDING_LOCK, 
> >> it seems there is a race condition here where a winFile object may think 
> >> it has tried (and possibly failed) to promote a SHARED_LOCK to an 
> >> EXCLUSIVE_LOCK without realizing that at least once, and possibly twice, 
> >> it was in a state where it held no lock at all.
> >>     
> >
> >
> >
> > -----------------------------------------------------------------------------
> > To unsubscribe, send email to [EMAIL PROTECTED]
> > -----------------------------------------------------------------------------
> >
> >
> >   
> 
> 
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
> 


-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to