> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 30, 2007 7:19 AM > To: sqlite-users@sqlite.org > Subject: [sqlite] Proposed sqlite3_initialize() interface > > As currently implemented, SQLite3 requires no initialization. > You just start calling SQLite3 interfaces and they work. We > can pull off this trick on Unix because pthread mutexes can > be initialized statically at compile-time. > > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; > > On win32, we have to initialize mutexes at run-time, but this > can be done within a contrived mutex that we build off of > a static integer using InterlockedIncrement(). And mutex > initialization apparently never fails on win32, so we do not > have to worry with reporting errors that occur during > mutex initialization. > > But there are other operating systems using SQLite that do > not work this way. They need a way to initialize mutexes > (and possibly other objects such as malloc) prior to running > any SQLite interface. And the initialization needs to be able > to fail and return an error code. >
Is there a reason this can't be checked/done in sqlit3_open() via an InterlockedCompareExchange() operation on the static integer, and if the mutexes don't exist and can't be created, you just return a different error code? Robert ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
