> > > latest CVS:
> > >
> > > #if SQLITE_THREADSAFE
> > > # include <pthread.h>
> > > # define SQLITE_UNIX_THREADS 1
> > > #endif
> > >
> >
> > I don't know where you are seeing this. The latest is
> >
> >
> > http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h&v1=1.592&v2=1.593
>
> Look in sqlite 3.4.2 os_unix.c.
>
> http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c&v=1.136
>
> Before 3.5 it was the only sqlite source file where thread-safety was relevant
> for UNIX.
I see what's going on now. I incorrectly assumed that both configure
builds and the amalgamation were both threadsafe by default in the
3.4.x sources.
It appears that a default ./configure without options for both 3.4.x
and the new 3.5 sources will result in a non-threadsafe build. This
has always been the case, since configure explicitly defines
-DTHREADSAFE=0 in the Makefile.
The sqlite3.c amalgamation, on the other hand, with no compile flags
does result in a threadsafe build for both 3.4.x and 3.5.
So the "threadsafe by default" cvs log comment in os_unix.c has to be
taken in context.
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------