> > > 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] -----------------------------------------------------------------------------