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