After reading Dan's response, I must be mis-interpreting these comments.
Please ignore.
--- Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- Richard Klein <[EMAIL PROTECTED]> wrote:
> > In implementing xLock in a VFS, do we need to worry
> > about lock counts, i.e. nested locking?
> >
> > In other words, if a process asks for, say, a SHARED
> > lock, and he already has one, should we increment a
> > SHARED lock count? Or is it okay to just return,
> > i.e. to treat the request as a no-op?
>
> See comments for unixLock() and unixUnlock() in os_unix.c.
>
> /*
> ** An instance of the following structure is allocated for each open
> ** inode on each thread with a different process ID. (Threads have
> ** different process IDs on linux, but not on most other unixes.)
> **
> ** A single inode can have multiple file descriptors, so each unixFile
> ** structure contains a pointer to an instance of this object and this
> ** object keeps a count of the number of unixFile pointing to it.
> */
> struct lockInfo {
> struct lockKey key; /* The lookup key */
> int cnt; /* Number of SHARED locks held */
> int locktype; /* One of SHARED_LOCK, RESERVED_LOCK etc. */
> int nRef; /* Number of pointers to this structure */
> };
>
> ...
>
> /* If a SHARED lock is requested, and some thread using this PID already
> ** has a SHARED or RESERVED lock, then increment reference counts and
> ** return SQLITE_OK.
> */
> if( locktype==SHARED_LOCK &&
> (pLock->locktype==SHARED_LOCK || pLock->locktype==RESERVED_LOCK) ){
> assert( locktype==SHARED_LOCK );
> assert( pFile->locktype==0 );
> assert( pLock->cnt>0 );
> pFile->locktype = SHARED_LOCK;
> pLock->cnt++;
> pFile->pOpen->nLock++;
> goto end_lock;
> }
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------