Nicolas Williams <[EMAIL PROTECTED]> wrote: > 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. >
Private messages on this subject suggest that I have misunderstood the question. What exactly do you mean by "instances" of SQLite? If you create two or more connections (two or more calls to sqlite3_open()) within the same process, they all share the same st_dev hash table and hence they all know about each others locks. If you create connections to the same databases from different processes, then they don't share the same st_dev hash, but posix advisory locking works in that case. In either case you are covered. Even if you are accessing SQLite from two different languages, you should only be linked against a single instance of the SQLite library (otherwise you would get linkage errors) meaning that you only have a single copy of the hash table. If you know of a way to link two copies of the same library into the same process at the same time, such that each copy of the library has its own set of static variables, then the conditions above break down and you cannot use SQLite safely. But on the other hand, I don't know of much software that is likely to survive such a scenario. And I am unclear how such a scenario is even possible. -- D. Richard Hipp <[EMAIL PROTECTED]> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
