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

Reply via email to