On Fri, Nov 18, 2016 at 8:38 AM, Roger Binns <rog...@rogerbinns.com> wrote:
> On 17/11/16 19:14, Kevin O'Gorman wrote: > > SO: I need help bifurcating this problem. For instance, how can I tell > if > > the fault lies in SQLite, or in python? Or even in the hardware, given > that > > the time to failure is so variable? > > Are you using threads, threading related settings etc in any way? The > python sqlite3 module (aka pysqlite) is not threadsafe. That doesn't > stop people "working around" it, which can lead to crashes. > > Roger > > > 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. These C programs have been in use for a number of months for earlier stages of this project, and I regard them as quite reliable. None of them uses threads, and they are mostly very simple filters. The one that runs in parallel cannot be the culprit, however, because the code has not reached the point where it would come into play. That is the step where the results get "cached" (in flat files) and all of the early results are in those files. This thing is dying before reaching unknown territory where new results are needed. The reason the results exist is that they were generated by previous versions of the software that did not use Python. I am switching because (a) I want a database instead of flat files for speed reasons and (b) the C code was getting too hard to maintain. All of this is a hobby project, and I can share any parts of it that you care to see. -- #define QUESTION ((bb) || (!bb)) /* Shakespeare */ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
