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.
To accomodate this need, we are considering an incompatible
API change to SQLite. We are thinking of requiring that an
application invoke:
int sqlite3_initialize(...);
prior to using any other SQLite interface. (The parameters to
sqlite3_initialize() are not yet designed.) It will be an error
to use any other SQLite interface without first invoking
sqlite3_initialize() exactly one. It is also an error to
invoke sqlite3_initialize() more than once.
Existing applications that use SQLite would have to be modified
to invoke sqlite3_initialize(). Presumably this would happen
very early in main(), before any threads were created. No other
code changes would be required.
This is still just an idea. If you think that adding a new
required sqlite3_initialize() interface would cause serious
hardship for your use of SQLite, please speak up now.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
