--- [EMAIL PROTECTED] wrote: > On some older versions of Linux, SQLite is unable to pass > database connections from one thread to another. But this > is a problem with the threading libraries used in those older > linux versions and is outside the control of SQLite. I do not > think this issue comes into play here.
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] -----------------------------------------------------------------------------
