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
