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