On Sep 4, 2005, at 5:53 AM, Igor Tandetnik wrote:
Christopher R. Palmer wrote:
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..
So SQLite locks the DB file immediately after opening a connection
in sqlite_open?
If all activity on the connection must be restricted to a single
thread, how is one to properly use sqlite3_interrupt?
Hi Igor,
I hope someone will correct me if I'm wrong, but it looks like
calling sqlite3_interrupt from another thread is okay-ish. It only
checks the sqlite3 struct's magic value to make sure it's legitimate
(closed, open, or busy), and then sets the SQLITE_Interrupt bit on
the flags field. I don't know if bit set and clear are atomic or not;
if not, and two threads happen to write into the flags field at the
same time, bad things can happen.
I just fixed my code to work with the new thread restrictions and
haven't had any problems calling sqlite3_interrupt from the UI thread
so far.
-D
