Dr. Hipp,

On the fly initialization is a big concern for me because I have the misfortune to live in a massively multi-threaded environment. So I am very much in favor of this change. I see that there are already some other proposals out there, but would urge you to make the interface change in the manner described because it maintains clarity. A single thread must initialize the sqlite module before any other operations are allowed. (You can enforce that with debug code.) I would also add one suggestion. Add a sqlite3_deinitialize() call as well. This function would be called after all other calls have completed and there are no more resources in use. While it may be a noop at this time, it may not be at some point. It is also a good place for debug code to ensure that all resources have been released.

Mark Spiegel

[EMAIL PROTECTED] wrote:
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]
-----------------------------------------------------------------------------




-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to