Ron Avriel wrote:
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.
Unfortunately, that's not the case. The code that was being used when I
created ticket 1272 was very simple. In the main thread, I opened a
handle for each thread. Each thread then worked independently using
only their own handle. This broke the locking because the low-level
Linux file locks are tied to the thread that created them. That is, the
thread that opened the handle..
Cheers,
Chris.
