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 upon the disk head positioning.
If you have a mutliple processor machine or a multiple core processor
then you have some parallel computing ability.
Uma Krishnan wrote:
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 PROTECTED]> wrote: Do you have parallel I/O or are you
using Windows or Unix?
Uma Krishnan wrote:
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 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 functionality and a structure
which is much simpler to prove correct.
I see situations where there is a complex web of worker threads etc
applied to what would otherwise be a simple problem. The result runs
slowly and has hidden race conditions and other defects. DRH's
reservations about threads come to mind.
Applications run best when they can be reduced to a single stream
without any synchronization requirements.
Threads are indispensible when multiplexing a user interface but are
very dispensible when handling a single resource like a database.
Joe Wilson wrote:
--- Ken 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 to simply to finish
(a.k.a. return) gracefully. That way you can avoid the lock timeout
and polling.
On the GUI thread, however a timeout and poll may be necessary
depending on the framework.
____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
