Dennis Jenkins wrote:
Rolf Schaeuble wrote:
Hello,
if I understand the whole issue correctly, there is only one reason
why it's not safe to use a sqlite handle in any thread of a process
(as long as only one thread at a time uses it): File locks are tied to
the thread that created them (except this special Redhat version).
That's why on Windows everything's safe, since file locks are
per-process there.
If that's correct, couldn't this problem be solved by letting sqlite
use a dedicated thread to do the locking? Each time a lock needed to
be set/removed, a message would be sent to that thread which then
would perform the locking. That should make it safe to use the sqlite*
from any thread.
For single threaded applications that would mean more thread
switching. For multithreaded applications, however, life wouldn't only
become easier, but performance may well increase. In my applications I
have a dedicated database access thread. Each time a query needs to be
executed, it's sent to this thread. In this case I have thread
switching anyway. Only having it when a lock is set/removed will
decrease the amount of switches.
Best regards
Rolf Schäuble
I disagree with the entire approach. It seems hackish.
Just have each thread create it's own sqlite handle. So long as one
thread does not need to "pass off" an exisiting handle to a different
thread you will be fine.
That doesn't work for me. During one single transaction several threads
need to insert data into the db; due to this transaction, all threads
have to share a single database handle.
I find it much more hackish that I have to implement a dedicated thread
that collects the data and writes it to the db. It's more code (thus
more bugs), and it causes more thread switching, so it's less efficient.
