This old mailing list thread better describes this proposed algorithm to contain all open/close/lock/unlock activity in a single work thread:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg15852.html --- Joe Wilson <[EMAIL PROTECTED]> wrote: > As you already know, it's not just Linux - it's a POSIX thing. > It's also true with FreeBSD and OpenBSD. (BSD fcntl man page below). > > It would be great if SQLite could remove this last vestage of not > being able to reliably pass connections between threads on UNIX. > One way to accomplish that is to have all low level UNIX open() and close() > calls be performed from a single thread. Regardless of whatever thread > initiates > the sqlite3_open or sqlite3_close, SQLite could populate a threadsafe > work queue with the open/close information and wait on a condition variable > for its successful completion. The same "don't close() the file until the > file ref-count is zero" trick would still have to be employed behind > the scenes. > > This interface follows the completely stupid semantics of System V and > IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated > with a file for a given process are removed when any file descriptor for > that file is closed by that process. This semantic means that applica- > tions must be aware of any files that a subroutine library may access. > For example if an application for updating the password file locks the > password file database while making the update, and then calls > getpwnam(3) to retrieve a record, the lock will be lost because > getpwnam(3) opens, reads, and closes the password database. The database > close will release all locks that the process has associated with the > database, even if the library routine never requested a lock on the data- > base. Another minor semantic problem with this interface is that locks > are not inherited by a child process created using the fork(2) system > call. The flock(2) interface has much more rational last close semantics > and allows locks to be inherited by child processes. The flock(2) system > call is recommended for applications that want to ensure the integrity of > their locks when using library routines or wish to pass locks to their > children. __________________________________________________ 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] -----------------------------------------------------------------------------
