Threads can certainly complicate and cause some horribly complicated bugs to
find, but if you're careful they're great for working on multiple things at
once.  The other alternative is a single thread that does many things.  At
that point you're basically writing co-operative multi-tasking code.  After
having seen a large system written that way I wouldn't recommend it (having
simple stack-based local per-thread storage is great compared to all of the
queues, etc that are needed to track many different operations and the state
each one happens to be in at each moment).  

> -----Original Message-----
> From: Jonas Sandman [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 04, 2007 9:49 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Threads in 3.5.0
> 
> Well I am certainly a newbie in this context, threads must certainly
> be used when writing Windows application since you are not at liberty
> to splinter your process like you can on a *nix based system, no?
> 
> On 10/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > John Stanton <[EMAIL PROTECTED]> wrote:
> > >
> > > When multi-processor machines are used thread usage may indeed
implement
> > > parallel processing when used appropriately and have tangible
benefits.
> > >
> >
> > True enough, in general.  But with SQLite 3.5, access to each
> > database connection is serialized.  So even though the interface
> > allows you to have 20 different threads all doing sqlite3_exec()
> > on the same connection at the same time, the SQL statements are
> > still being processed one by one, regardless of how many CPUs
> > you devote to the task.
> >
> > --
> > D. Richard Hipp <[EMAIL PROTECTED]>
> >
> >
> >
----------------------------------------------------------------------------
-
> > To unsubscribe, send email to [EMAIL PROTECTED]
> >
----------------------------------------------------------------------------
-
> >
> >
> 
>
----------------------------------------------------------------------------
-
> To unsubscribe, send email to [EMAIL PROTECTED]
>
----------------------------------------------------------------------------
-


-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to