Florian Weimer <[EMAIL PROTECTED]> wrote: > > As long as no prepared statements are outstanding, you should > > be safe moving sqlite database connections across threads, as > > of version 3.3.1. The rules are not really quite that strict, > > but the exact rules are more complex and this strict rule > > gives you an extra margin of safety. > > Is it possible to finalize statements in a separate thread? This > would be a rather important feature because on most multi-threaded > VMs, user-defined finalizers (which would be used to clean up SQLite > objects which are no longer used) run in a separate thread. >
It is possible to construct a case where finalizing a statement from a different thread that the one where it was last stepped would cause a problem. Remember, that the operating system bug that is causing all the multithreading grief is that file locks created by one thread cannot be reliably removed or modified by a different thread. So if a statement acquires a lock on the database file in one thread and you try to finalize the statement in a different thread, the finalization would involve releasing the lock in a different thread from which it was acquired - an operation that silently fails on certain Linux kernels. On the other hand, if you sqlite3_reset() all statements in the thread where they were last run, then all locks are released by the reset. Then you are free to finialize the statements from any thread you want. -- D. Richard Hipp <[EMAIL PROTECTED]>
