Dan Kennedy wrote:
From SQLite's point of view, locks are on a per file-handle basis. If
a unix process that uses sqlite has two file-handles open on the same
file (i.e. because the user has opened two separate connections with
two calls to sqlite3_open()), SQLite expects them to be able to
obtain and hold locks independently. A shared lock on one handle
should prevent obtaining an exclusive lock on the other, just as it
would if the two handles were opened by different processes. If a
shared lock is obtained on both handles, then released on one, SQLite
expects that the other handle still holds it's shared lock.
That's what I thought.
The above paragraph describes how sqlite expects the vfs implementation
to work. Unix doesn't share this simple view of the world, so the
implementation of sqlite3_vfs for unix has to jump through all sorts
of hoops to implement it.
The embedded OS for which I am implementing a VFS doesn't have any
sort of file locking primitives. The downside of this is that I have
to implement the locking mechanism from scratch. The upside is that
I don't have any weird side effects to workaround, so I can make the
locking work exactly the way it's supposed to. :-)
So when I say you don't need to worry about reference counting, I
mean if sqlite calls xLock() on a file-handle twice, then xUnlock()
once, the file-handle should move into the "unlocked" state.
That's *exactly* what I wanted to know. Thanks again, Dan and Joe!
- Richard
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
