Mrs. Brisby wrote:
meanwhile, two threads attempting to multiplex access to a single sqlite
handle are a) bound to be confused, and b) need those resource locks
anyway.
(background: I've been using threads on win32 since 1998. Sometimes to
spread load across multiple CPUs, but usually just because I find it
simpler than state logic to do everything in one thread. I'm not
entering into this debate on threads vs. non-threads.)
I just want to know why anyone would code using multiple threads
accessing the same SQLITE connection object ( or handle or whatever you
want to call it). I allocate a separate connection object for each
thread and have ZERO troubles with locking so long as I use transactions
properly. Assuming a multi-threaded (with in the same process)
environment, what benefits are there to use a single (global?) SQLITE
object (protected by a mutex, semaphore, critical section, whatever)?
It seems so much more complicated and brittle.
