----- Original Message ----- From: "Rolf Schaeuble"
<[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, September 14, 2005 2:43 PM
Subject: Re: [sqlite] Re: Thread safety guarantees
That doesn't work for me. During one single transaction several
threads need to insert data into the db; due to this transaction, all
threads have to share a single database handle.
I find it much more hackish that I have to implement a dedicated
thread that collects the data and writes it to the db. It's more code
(thus more bugs), and it causes more thread switching, so it's less
efficient.
You must already be doing some sort of synchronization here, though.
Afterall, you can't have all those threads all issuing SQL commands
against the same connection pointer at the same time without some sort
of mutex.
Of course this is synchronized. The producer threads put their data into
a (threadsafe) queue, which is then taken by the consumer thread and
written into the database. This means only one single thread is issuing
SQL commands.
This consumer thread I want to get rid of. If the engine would implement
locking in a way that is not tied to one single thread, each of my
threads could execute the commands directly (of course only one thread
at a time, e.g. protected by a mutex). That would mean one less thread
running.
