--- Ken [EMAIL PROTECTED] wrote:
In general I'v found that Thread cancellation is very painful,
a simpler paradigm to utilize is the lock timeout with a Global
variable status check.
Rather than check a global variable you could simply pass a null
event to the queue which instructs the thread
One of the ignored points about thread usage is just how expensive are
the synchronization mechanisms. It is a good idea to apply Occam's
Razor to your design and eliminate unnecessary features and have a
result which provides a better level of functionality and a structure
which is much
How about when you need to take advantage of parallel I/O etc, or you need to
access multiple SQLite databases w/i a transaction?
Are you dissuading thread usage from DB application point of view, or even
within SQLite kernel?
Thanks in advance
- Uma
John Stanton [EMAIL PROTECTED] wrote:
--- John Stanton [EMAIL PROTECTED] wrote:
One of the ignored points about thread usage is just how expensive are
the synchronization mechanisms. It is a good idea to apply Occam's
Razor to your design and eliminate unnecessary features and have a
result which provides a better level of
No I'm not currently parallel I/O. But I was hoping to use multiple Sqlite
databases (in-memory, disk based etc), and wanted to know the recommended
policy in that case. At present, since SQLite is a single file, there can be no
parallel I/O within a single DB - right?
John Stanton [EMAIL
If you machine has a single disk it fundamentally does not have parallel
I/O. If you have a machine with multiple dik spindles and multiple
channels then you can have parallel access. Multiple Sqlite databases
residing on the same disk are accessed sequentially because the access
depends
- Original Message
From: John Stanton [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
Sent: Wednesday, November 14, 2007 11:43:48 AM
Subject: Re: [sqlite] Re: Threads
If you machine has a single disk it fundamentally does not have parallel
I/O. If you have a machine with multiple
On 11/14/07, John Stanton [EMAIL PROTECTED] wrote:
Threads simulated in software are a kludge to better utilize current
processor and operating system architectures. In time machines where
the parallelism is handled in hardware will be more widely available and
the threading will be
The simple answer is that current mass-market machines and software
strongly resist parallel processing. Newer architectures allow for
massively parallel execution and support software which can take
advantage of it fairly transparently. Each one needs to be used in such
a way as to maximize
