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