On 9/3/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > > This is not portable. Some operating systems (ex: RedHat) > will cause intermittent problems if the same SQLite handle > is used by more than one thread. The program will seem to > work initially but will begin to exhibit unreproducible > errors under heavy load. This is a problem in the design > of the operating system and there is nothing that SQLite > can do to prevent it. In order to avoid these problems and > for your software to be portable, each SQLite handle must > be used by only a single thread - specifically the thread > that opened it. If you want to use SQLite in a multi- > threaded application, then open a separate handle for > each thread. >
As I understand from all previous Linux multithreading problems http://www.sqlite.org/cvstrac/tktview?tn=1272 http://www.sqlite.org/cvstrac/chngview?cn=2521 http://www.sqlite.org/cvstrac/tktview?tn=1285 they were all caused by *simultaneous* use of the same handle in different threads. If the application ensures that a handle is used to execute queries by *only one thread at a time*, as mentioned in level 2 above, I don't see any reason for multihreading problems. I think that the new multihreading restriction from version 3.2.5, described as level 1 above, imposes a very hard limitation. It's impractical for my multithreaded Linux application to open many hundreds of handles instead of around ten. If SQLite wants to ensure it is not being abused can't it check multithreading abuse from sqlite3_prepare() until sqlite3_step() as in level 2 above, thus enabling a serialized handle pool? I've tested SQLite heavily in a multithreaded Linux application with a serialized access of all threads to a single handle and encountered no problems. On the other hand, would it be safe to compile SQLite with -DTHREADSAFE=0, thus disabling thread checks, and use a serialized handle pool in a multithreaded Linux application? Thanks, Ron
