[GNUnet-developers] Re: Fwd: Threadsafe SQLite

[drh]

"N. Durner" <address@hidden> wrote:
> -------- Original-Nachricht --------
> Betreff:      Threadsafe SQLite
> Datum:        Fri, 30 Sep 2005 21:06:08 +0200
> Von:  N. Durner <address@hidden>
> An:   address@hidden
> CC:   address@hidden <address@hidden>
> 
> the GPL'ed application GNUnet opens a SQLite DB inside the main thread
> and uses statements that were prepared there in a few other threads
> (protected by mutexes).
> If SQLite was built with "--enable-threadsafe" (as Debian's
> "libsqlite3-0" package), sqlite3_step fails with "library routine called
> out of sequence".
> 
> The FAQ says:
> ---
> An *sqlite3* structure can only be used in the same thread that called
> sqlite3_open <http://www.sqlite.org/capi3ref#sqlite3_open> to create it.
> You cannot open a database in one thread then pass the handle off to
> another thread for it to use.
> ---
> But this is only true for Unix builds compiled with
> "--enable-threadsafe" (os_unix.c:1050). Statements prepared in the way
> described above work on Win32 (os_win.c:628) and if SQLite isn't threadsafe.
> 
> Is this behavior really intended?
> 

Yes.  These restrictions are necessary in order to work around
bugs in Linux as manifest in RedHat 9.  See

   http://www.sqlite.org/cvstrac/tktview?tn=1272
   http://www.sqlite.org/cvstrac/tktview?tn=1285

Methods for relaxing these constraints somewhat have been proposed.
But they are very difficult to test reliably.  (How do you ever
truely know that a multi-threaded program really works???)  Hence,
the changes have not been moved into the core.  We feel that it
is much more important to have an implementation that works
reliably than to have one that pushes the envelope with threads.

Your statement above that it "works if threadsafe is not enabled" is
false.  What you mean is that you did not notice any problems on
your system.  If you put the program under a heavy load on RedHat 9
(and some other versions of linux) you will likely begin to see
occasional hard-to-reproduce failures.
--
D. Richard Hipp <address@hidden>