On 18/11/16 08:55, Kevin O'Gorman wrote: >> I am not. All of the python code is a single thread. The closest I come > is a few times where I use subprocess.Popen to create what amounts to a > pipeline, and one place where I start a number of copies of a C program in > parallel, but each is a separate process with its own input and output > files.
Ding ding ding. You didn't mention which version of Python. Popen calls fork (it seems like you are doing Unix/Mac, not Windows). fork() duplicates the process including all open file descriptors. One or more of those descriptors belong to open SQLite databases and ancillary files. If the child process does virtually anything, it will result in crashes. Examples of doing things include: - Running any Python code (destructors can be called which then run in the parent and child) - Not having file descriptors closed so the child process trashes them (close_fds Popen argument is False in python 2.x but True in python 3.x). Also python 2.x subprocess module is broken in many ways. There are three methods for addressing this assuming it is the cause. 0: Python 3 is safer if you aren't already using it. The subprocess32 module for Python 2 backports Python 3 subprocess if you are stuck on Python 2 1: Make sure that the process that does SQLite work is a "leaf". ie it doesn't call subprocess or make any child processes. Instead a master process feeds it data on its stdin/out 2: Switch to APSW which has a fork checker built in. This will catch the fork problem no matter how it happens, and whatever is going on in other libraries you may use: https://rogerbinns.github.io/apsw/apsw.html?highlight=fork#apsw.fork_checker Disclaimer: I am the author of APSW Roger
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
