Re: sqlite threadsafe

On Tue, 20 Nov 2007, David Glasser wrote:

> On Nov 19, 2007 4:59 PM, Dan Christian <dchristian@google.com> wrote:
> > Argh! Not this again. openssl has similar problems (under serf).
> >
> > On Nov 19, 2007 1:46 PM, David Glasser <glasser@davidglasser.net> wrote:
> > > Apparently SQLite requires you to compile it with -DSQLITE_THREADSAFE
> > > to be at all threadsafe. (There's a way to check at runtime
> > > (sqlite3_threadsafe()) if this is so, but that's an experimental API
> > > that may vanish.)
> >
> > Don't let it vanish. Runtime checks are the only foolproof way to verify this.
>
> "Don't let it vanish" may be backwards, sadly, since the API doesn't
> seem to have shown up until 3.5 (and we're already having issues with
> Etch not supporting even 3.3.9 for an API).

And the C preprocessor token SQLITE_THREADSAFE seems to have been in use
before that, bleh.

> > > Should we add something to INSTALL telling people they must build
> > > against a threadsafe SQLite if they are going to be using a thready
> > > server?
> >
> > YES! And configure should verify this. Otherwise, it looks like
> > subversion is flaky.
>
> I don't think it can verify it unless we require 3.5.

Yup. We could use sqlite3_threadsafe() if we can safely detect it runtime
for dynamic builds of Subversion (e.g. via dlopen()), or via configure checks
for static Subversion builds. While not ideal, this would allow us to detect
cases where newer versions of SQLite which do provide sqlite3_threadsafe()
were not compiled with -DSQLITE_THREADSAFE=1.

I would really prefer to avoid bundling SQLite with Subversion.

-- 
Daniel Rall