(6) is SQLite threadsafe?
SQLite is threadsafe. we make this concession since into users choose to ignore the advice given in the previous paragraph. but in order to be thread-safe, SQLite must be compiled with the sqlite_threadsafe Preprocessor macro set to 1. both the Windows and Linux precompiled binaries in the distribution are compiled this way. if you are unsure if the SQLite library you are linking against is compiled to be threadsafe you can call the sqlite3_threadsafe () interface to find out.
Prior to version 3.3.1, an sqlite3 structure cocould only be used in the same thread that called sqlite3_open () to create it. you cocould not open a database in one thread then pass the handle off to another thread for it to use. this was due to limitations (bugs ?) In every common threading implementations such as on redhat9. specifically, an fcntl () Lock created by one thread cannot be removed or modified by a different thread on the troublesome systems. and since SQLite uses fcntl () locks heavily for concurrency control, serious problems arose if you start moving database connections across threads.
The restriction on moving database connections across threads was relaxed somewhat in version 3.3.1. with that and subsequent versions, it is safe to move a connection handle into SS threads as long as the connection is not holding any fcntl () locks.
You can safely assume that no locks are being held if no transaction is pending and all statements have been finalized.
Under UNIX, you shoshould not carry an open SQLite database into ss a fork () system call into the child process. Problems will result if you do.