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] -----------------------------------------------------------------------------