On 18/12/2019 00.56, Gregory P. Smith wrote:
On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom <Tom.Kacvinsky@vector..com <mailto:Tom.Kacvinsky@vector.com>> wrote:
We ran into an issue where having the SQLite library built with -DSQLITE_THREADSAFE=0, but then the sqlite3 module (really, the _sqlite3.so0 crashing in threading code. So I have to ask if it is intended that the sqlite3 Python module always be built with a thread safe SQLite library.
Thanks,
Tom
Given your experience I think you've answered the question: Yes. But it would be good if we could detect this at build time (is there a way to do that?) and prevent the module from being built against the sqlite3 library compiled in this unusual mode.. Threading support is required in order to be a valid CPython platform, so all libraries used should be aware of that.
We have to detect the problem at run-time. Compile time is not sufficient. It's possible to compile Python with a thread-safe version of libsqlite3, then run Python with a unsafe version of libsqlite3. sqlite3 has two APIs to query thread safety and three different settings for threading: sqlite3_threadsafe() sqlite3_config() SQLITE_CONFIG_SINGLETHREAD SQLITE_CONFIG_MULTITHREAD SQLITE_CONFIG_SERIALIZED Only serialized is fully thread safe. I would start by checking that (sqlite3_threadsafe() == SQLITE_CONFIG_SERIALIZED). Christian