Re: sqlite threadsafe

On Wed, 21 Nov 2007, Daniel L. Rall wrote:

> On Wed, 21 Nov 2007, Philip Martin wrote:
...
> > If I understand this correctly you are attempting to dlopen a shared
> > library that is already dynamically linked to the executable. My
> > first reaction is yuck!
>
> Yes, that's right. The idea was to suppor the use case where Subversion is
> dynamically linked against a pre-3.5 version of SQLite (which basically every
> current OS and package management is using), then SQLite is later upgraded.
> Personally, I tend to do updates like this all the time.
>
> > That will only work if apr_dso_load uses the
> > same search path as the linker, and I seem to recall that people have
> > problems running the tests when RA/FS are loaded using apr_dso_load as
> > the search path doesn't do what we want, it doesn't include the build
> > tree for example.
>
> On Linux and Mac OS X, apr_dso_load() wraps dlopen(), which DTRT for an
> installed Subversion. I'm unsure about Windows, and also about uninstalled
> builds used for testing which have dynamic linkage (would rpath come into
> play here an help out?).
>
> I did have some concern about someone building against a SQLite that's not
> in the standard loader path, then getting unexpected behavior at runtime
> if the loader picks up a different version of SQLite.
>
> > I think you should avoid apr_dso_load, if configure doesn't detect
> > sqlite_threadsafe then it should simply do not call it.
>
> I considered this (and am certainly not against it), but it does fail to
> take advantage of SQLite's thread-safety checks when upgrades occur and
> they become available, a case which will be very common over the next couple
> years. This is somewhat balanced out by the fact that the thread-safe mode
> is the default in the latest SQLite CVS.
...

I committed the portion you were okay with in r27979. I'm attaching the
portion that I held back for the moment.

We might also want to use the DSO stuff to deal with the scenario where a new
SQLite is available at Subversion compile-time, but not at runtime (e.g. due
to downgrade), if we're going to claim to support all of 3.x. Then again,
might be too much flexibility.

-- 
Daniel Rall