On Wed, Feb 20, 2008 at 04:23:29PM +0000, [EMAIL PROTECTED] wrote:
> Nicolas Williams <[EMAIL PROTECTED]> wrote:
> > does SQLite know about POSIX file locks on the same files from
> > other instances of itself?
> 
> Yes.  That's the whole point of POSIX advisory locking.

src/os_unix.c says:

** Here is the dirt on POSIX advisory locks:  ANSI STD 1003.1 (1996)
** section 6.5.2.2 lines 483 through 490 specify that when a process
** sets or clears a lock, that operation overrides any prior locks set
** by the same process.  It does not explicitly say so, but this implies
** that it overrides locks set by the same process using a different
** file descriptor.  Consider this test case:
...
** To work around the problem, SQLite has to manage file locks internally
** on its own.  Whenever a new database is opened, we have to find the
** specific inode of the database file (the inode is determined by the
** st_dev and st_ino fields of the stat structure that fstat() fills in)
** and check for locks already existing on that inode.  When locks are
** created or removed, we have to look at our own internal record of the
** locks to see if another thread has previously set a lock on that same
** inode.
...

Now, SQLite maintains an internal hash table indexed by st_dev and
st_ino, but if there are two _distinct_ copies of SQLite in the same
process, how can those two instances of SQLite share that hash table?

The hash table is a static, after all, so each instance of SQLite will
have its own instance of that hash table, which will mean they won't
know about each other's locks.

Nico
-- 
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to