On Thu, 2005-07-28 at 07:42 -0500, Dennis Jenkins wrote: > 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 find I use goto a lot. I find it's simpler than lots of if/break scenarios. I think you'd be surprised to find out that you might actually agree with me :) > 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. The reason they would write their code this way is because they don't know how to use threads. They think threads work differently than they do. And folks, this here is my whole point. Coming from the position of someone who knows how to use threads: Why would anyone chose to use them incorrectly. The only reasonable answer is that they simply don't know how to use threads. Threads complicate things. People think they "understand threads" long before they actually do. Goto complicates things. People think they "understand goto" long before they actually do. They think they know the dangers of threads, and they think they know the dangers of goto. And yet, there are folks who vehemently avoid "goto" as if it were a plague, that simply don't understand why people would just as aggressively reject "threads".
