"Ron, Shac" <[EMAIL PROTECTED]> wrote: > > Does this mean that issues pertaining to threads, particularly in > passing a sqlite3* between threads, are now resolved?
This issue is a bug in some versions of Linux (2.4 kernels with particular combinations of pthreads and glibc.) The problem is that fcntl locks created in one thread could not be modified by a different thread in the same process. SQLite 3.3.1 added code to work around this bug. What is does is to partially close then reopen the connection to the database when it detects that the connection has been moved to a different thread. (It only does this on kernels that exhibit the bug, so there is no overhead for working systems.) But this work-around only works if the connection is not currently holding a lock. So, in version 3.3.1, it is safe to move database connections between threads if no locks are held. Another way to think about it is that it is safe to move connections as long as there are no unfinalized statements open on that connection and you are not in the middle of a transaction. This is a more strict requirement than is absolutely necessary, but it is easier to understand. It is still not safe to call sqlite3_finalize() on a statement that was sqlite3_step()-ed in a different thread. The sqlite3_step() might have created a lock that sqlite3_finalize() will want to remove but cannot because of the bug in Linux. -- D. Richard Hipp <[EMAIL PROTECTED]>
