which gives me the opportunity to repear my oft-ignored reply :) what you say is true, provided the OS is geared towards multiple processes. which is not true for windows, but is true for *ix, as400 and other environments. if you need, say, a server that handles 500 sessions, and attempt to do this with spawning processes on windows, you are probably dead, memory and cpu-wise. on Linux, this is nothing, it can handle it easily. otoh, 500 threads for windows is business as usual, but threading on Linux, is , I hear, iffy at best.
so, although this is good advice, it is not unconditionally applicable. > -----Original Message----- > From: D. Richard Hipp [mailto:[EMAIL PROTECTED] > Sent: Friday, July 15, 2005 3:27 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Multi-threading. > > On Fri, 2005-07-15 at 16:41 +0530, Roushan Ali wrote: > > Hello all, > > Can we use single sqlite_open handle(global) > across threads( > > if all database operations are serialized by using > semaphore) ? Please > > help. > > > > Opening a database connection in one thread and using it in > another will work on some operating systems but not on > others. You are advised not to do it. See > http://www.sqlite.org/cvstrac/tktview?tn=1272 > and http://www.sqlite.org/cvstrac/chngview?cn=2521. > > Actually, this seems like a good opportunity to repeat my > oft-ignored advice to not use more than one thread in a > single address space. If you need multiple threads, create > multiple processes. This has nothing to do with SQLite = it > is just good programming advice. I have worked on countless > multi- threaded programs over the years, and I have yet to > see a single one that didn't contain subtle, hard to > reproduce, and very hard to troubleshoot bugs related to > threading issues. > > I am constantly amazed at the prevailing idea (exemplified by > Java) that software should be strongly typed and should not > use goto statement or pointers - all in the name of reducing > bugs - but that it is OK to use multiple threads within the > same address space. Strong typing helps prevent only bugs > that are trivially easy to locate and fix. The use of goto > statements and pointers likewise results in deterministic > problems that are easy to test for and relatively easy to > track down and correct. But threading bugs tend to manifest > themselves as timing-dependent glitches and lock-ups that are > hardware and platform dependent, that never happen the same > way twice, and that only appear for customers after > deployment and never in a testing environment. > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > >
