Re: [sqlite] Proposed sqlite3_initialize() interface
> 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. It requires changing and recompiling all applications linking to it. This is a bit annoying for distributions. Debian would probably have to ship an sqlite3 and sqlite4 (?) package until the transition is done. I think the list of affected functions you posted is overly pessimistic; most of these functions probably do not need a fully initialized library. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
On Oct 30, 2007 6:32 PM, Russell Leighton <[EMAIL PROTECTED]> wrote: > > On Oct 30, 2007, at 10:18 AM, [EMAIL PROTECTED] wrote: > > > > > 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(...); > > > > I am not sure about the systems that you are trying to support, but for > gnu tool chain you can do: You may have noticed that the purpose of this function is to return some useful failure information on platforms which can err. -- Cory Nelson - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Proposed sqlite3_initialize() interface
gcc support this, msvc++ and other compilers does not. -Original Message- From: Russell Leighton [mailto:[EMAIL PROTECTED] Sent: terça-feira, 30 de outubro de 2007 23:32 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Proposed sqlite3_initialize() interface On Oct 30, 2007, at 10:18 AM, [EMAIL PROTECTED] wrote: > > 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(...); > I am not sure about the systems that you are trying to support, but for gnu tool chain you can do: gcc -shared -Wl,-init=sqlite3_initialize ... which will run the function at library load time and for static linking ( I think you can use this for dynamic linking too but I am not sure): __attribute__((constructor)) void sqlite3_initialize(void) So the init function would not need to be a public function and no API change would be needed (assuming the target platforms have similar capability). - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
On Oct 30, 2007, at 10:18 AM, [EMAIL PROTECTED] wrote: 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(...); I am not sure about the systems that you are trying to support, but for gnu tool chain you can do: gcc -shared -Wl,-init=sqlite3_initialize ... which will run the function at library load time and for static linking ( I think you can use this for dynamic linking too but I am not sure): __attribute__((constructor)) void sqlite3_initialize(void) So the init function would not need to be a public function and no API change would be needed (assuming the target platforms have similar capability). - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
On Tue, 30 Oct 2007 14:18:48 +, [EMAIL PROTECTED] wrote: >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. In my environment SQLite is used mostly in batch via the command line tool, in PHP (via PDO), and using sqlite3explorer (a great SQLite GUI frontend by Mike Cariotoglou). Of course the command line tool gives no issues at all. Implementation of sqlite3_initialize in PHP might take quite some time, but as long as the dbfile format stays the same that won't be a problem, as we will be using the PHP-specific library version anyway. I hope Mike Cariotoglou is willing to update sqlite3explorer ;) The same probably goes for other less actively maintained frontends. -- ( Kees Nuyt ) c[_] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
[EMAIL PROTECTED] wrote: 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. This is true of the Porter layer that we use on our set-top boxes. I had to add sqlite_initialize(...) and sqlite_finalize(...) functions when I ported SQLite 2 to our Porter. 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(...); Sounds good to me. I would also recommend adding: int sqlite3_finalize(...); - Richard Klein - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
I wrote: > On 10/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > 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. > > That isn't actually true, but handling that particular, rare > out-of-memory error condition that can occur with CriticalSections is > so amazingly inconvenient that most people don't even bother trying :) I realize how fragile that sounds, so to expand a bit: the default behavior is for the process to die immediately. It's sort of like getting a signal when you hit a ulimit on unix. There's no danger of silent failure and mysterious problems later. I'd consider it to be in roughly the same class as handling running out of stack during execution. Not a bug, just not something designed for. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
On 10/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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. That isn't actually true, but handling that particular, rare out-of-memory error condition that can occur with CriticalSections is so amazingly inconvenient that most people don't even bother trying :) > 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. Some thoughts: * Definitely a major version change. * In order to correctly handle dynamic library scenarios, there needs to be a pair of initialize/finalize functions, and they need to be counted. The first intitialize() does the work, the rest simply increment a counter. The last finalize() does the work, the rest simply decrement. * For future flexibility, I'd suggest making one of the arguments to initialize() be a pointer to a struct. The first member of the struct should be a version indicator, like the VFS interface. - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Proposed sqlite3_initialize() interface
Roger Binns wrote: > [EMAIL PROTECTED] wrote: > > It is also an error to > > invoke sqlite3_initialize() more than once. > > That is a pretty nasty restriction to have. If you link multiple other > libraries into your program, each of which also uses SQLite then you'd > somehow have to arrange that only one of them calls sqlite3_initialize > which is a serious pain. I concur: having a required initialization function is not too bad, but it is more elegant to only require that initialize/cleanup be called in nested pairs (or just to allow arbitrary numbers of calls to initialize if cleanup is a no-op). For my uses of SQLite3 from C++, it is trivial to guarantee that an initialization function is called prior to any other calls. It's not even very hard to add another check to ensure that it's called once only, but I can see *most* clients having to do the same, which is a strong argument for doing it in the library (even such an elegantly minimal library as SQLite3). -- James - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
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] -
Re: [sqlite] Proposed sqlite3_initialize() interface
On Oct 30, 2007 7:18 AM, <[EMAIL PROTECTED]> wrote: > 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. I think this would cause some hardship for dynamically-loaded libraries which are using SQLite and which are multi-threaded. I don't think it's a SERIOUS hardship, because you can usually find (or annoint) some special place in your code to make the call (though that assumption might fail given a broad enough set of operating environments). If sqlite_initialize() needed to be called once per process, it would be handy if it could be called from any thread, and if it could safely be called multiple times. Alternately, it might be reasonable to require it to be called once per thread before anything else in that thread calls into SQLite. It would seem reasonable to me to have SQLite handle this initialization at appropriate entry points, and to add something like SQLITE_OMIT_AUTO_INITIALIZE for those users who can't afford the overhead. -scott - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
"Dan Petitt" <[EMAIL PROTECTED]> wrote: > > Alternatively, you don't actually need the interface for > > 99.99% of users out there (Windows, Linux, Mac) so you > > could make it unnecessary for them, but do require it for the > > various esoteric embedded systems. That would justify still > > calling it SQLite version 3. > > That was my first thought, just require it for the OS's that need it; all > other systems are unchanged and work as before. > Having sqlite3_initialize() is only *required* on some obscure systems. But it would certainly be *helpful* on Linux and Win32. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
--- Marco Bambini <[EMAIL PROTECTED]> wrote: > I think that sqlite3_initialize should be allowed to be called more > than once. > With the help of a static flag, only the first time it is executed > the proper initialize functions will be invoked, successive calls to > the sqlite3_initialize should just be a NOP operation... In a single-threaded program, perhaps. But in a multi-threaded program beware the Double Checked Lock: http://en.wikipedia.org/wiki/Double-checked_locking http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
I would endorse the use of an initialization functions as being clean and efficient and one of the simplest and most logical of optimizations, eliminating common expressions. Since your typical application program has an initialization phase it is trivial to add the new API function to legacy applications. Joe Wilson wrote: I think the proposed sqlite3_initialize() is a good idea and the library might be a bit smaller/faster as well due to removal of initialization checks in various functions. Any concern about operating systems that already ship with a shared sqlite3 library? Or is that what shared library version numbers are for? --- [EMAIL PROTECTED] wrote: "Robert Simpson" <[EMAIL PROTECTED]> wrote: 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? That's the other option. Though we would have to do this on multiple interfaces. Here is a list (complete, I think) off all SQLite interfaces that can be called "first" and would thus need to have the test you propose: sqlite3_auto_extension sqlite3_complete sqlite3_complete16 sqlite3_enable_load_extension sqlite3_enable_shared_cache sqlite3_global_recover sqlite3_libversion sqlite3_libversion_number sqlite3_load_extension sqlite3_malloc sqlite3_memory_alarm sqlite3_memory_highwater sqlite3_memory_used sqlite3_mprintf sqlite3_mutex_alloc sqlite3_open sqlite3_open16 sqlite3_open_v2 sqlite3_realloc sqlite3_release_memory sqlite3_reset_auto_extension sqlite3_sleep sqlite3_snprintf sqlite3_soft_heap_limit sqlite3_thread_cleanup sqlite3_threadsafe sqlite3_vfs_find sqlite3_vfs_register sqlite3_vfs_unregister sqlite3_vmprintf -- D. Richard Hipp <[EMAIL PROTECTED]> __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Proposed sqlite3_initialize() interface
> Alternatively, you don't actually need the interface for 99.99% of users out there (Windows, Linux, Mac) > so you could make it unnecessary for them, but do require it for the various esoteric embedded systems. > That would justify still calling it SQLite version 3. That was my first thought, just require it for the OS's that need it; all other systems are unchanged and work as before. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
I think that sqlite3_initialize should be allowed to be called more than once. With the help of a static flag, only the first time it is executed the proper initialize functions will be invoked, successive calls to the sqlite3_initialize should just be a NOP operation... --- Marco Bambini http://www.sqlabs.net http://www.sqlabs.net/blog/ http://www.sqlabs.net/realsqlserver/ On Oct 30, 2007, at 5:14 PM, Roger Binns wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: It is also an error to invoke sqlite3_initialize() more than once. That is a pretty nasty restriction to have. If you link multiple other libraries into your program, each of which also uses SQLite then you'd somehow have to arrange that only one of them calls sqlite3_initialize which is a serious pain. (The wxPython gui library used to have a similar issue when initializing things like cursors and colours and caused endless grief before it was fixed to allow multiple calls). In any event this is a very serious API change and really does qualify for calling it SQLite 4. Alternatively, you don't actually need the interface for 99.99% of users out there (Windows, Linux, Mac) so you could make it unnecessary for them, but do require it for the various esoteric embedded systems. That would justify still calling it SQLite version 3. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHJ1hXmOOfHg372QQRAjCHAKCdH4R/OQNY3ALUli9nRCmbFeyDfACeIHcY 7irdFT/ofCgoNK0jERTjze8= =yB1W -END PGP SIGNATURE- -- --- To unsubscribe, send email to [EMAIL PROTECTED] -- --- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > It is also an error to > invoke sqlite3_initialize() more than once. That is a pretty nasty restriction to have. If you link multiple other libraries into your program, each of which also uses SQLite then you'd somehow have to arrange that only one of them calls sqlite3_initialize which is a serious pain. (The wxPython gui library used to have a similar issue when initializing things like cursors and colours and caused endless grief before it was fixed to allow multiple calls). In any event this is a very serious API change and really does qualify for calling it SQLite 4. Alternatively, you don't actually need the interface for 99.99% of users out there (Windows, Linux, Mac) so you could make it unnecessary for them, but do require it for the various esoteric embedded systems. That would justify still calling it SQLite version 3. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHJ1hXmOOfHg372QQRAjCHAKCdH4R/OQNY3ALUli9nRCmbFeyDfACeIHcY 7irdFT/ofCgoNK0jERTjze8= =yB1W -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
On Oct 30, 2007, at 7:18 AM, [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. I assume (hope) you mean threads that call into sqlite3. We have a situation where 'sqlite3_initialize' would be called far away from any 'main' - sqlite3 is a runtime loaded extension for the Chicken Scheme system. There isn't any guarantee when the extension is loaded, and therefore when the initialization is done. I doubt any problems but just a heads up that sqlite3 is used in a manner differing from the above scenario by languages such as Scheme, Io, Lua, OCaml, etc. 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] -- --- Best Wishes, Kon - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
I think the proposed sqlite3_initialize() is a good idea and the library might be a bit smaller/faster as well due to removal of initialization checks in various functions. Any concern about operating systems that already ship with a shared sqlite3 library? Or is that what shared library version numbers are for? --- [EMAIL PROTECTED] wrote: > "Robert Simpson" <[EMAIL PROTECTED]> wrote: > > > > 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? > > > > That's the other option. Though we would have to do this on > multiple interfaces. Here is a list (complete, I think) off > all SQLite interfaces that can be called "first" and would > thus need to have the test you propose: > > sqlite3_auto_extension > sqlite3_complete > sqlite3_complete16 > sqlite3_enable_load_extension > sqlite3_enable_shared_cache > sqlite3_global_recover > sqlite3_libversion > sqlite3_libversion_number > sqlite3_load_extension > sqlite3_malloc > sqlite3_memory_alarm > sqlite3_memory_highwater > sqlite3_memory_used > sqlite3_mprintf > sqlite3_mutex_alloc > sqlite3_open > sqlite3_open16 > sqlite3_open_v2 > sqlite3_realloc > sqlite3_release_memory > sqlite3_reset_auto_extension > sqlite3_sleep > sqlite3_snprintf > sqlite3_soft_heap_limit > sqlite3_thread_cleanup > sqlite3_threadsafe > sqlite3_vfs_find > sqlite3_vfs_register > sqlite3_vfs_unregister > sqlite3_vmprintf > > -- > D. Richard Hipp <[EMAIL PROTECTED]> __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Proposed sqlite3_initialize() interface
"Robert Simpson" <[EMAIL PROTECTED]> wrote: > > 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? > That's the other option. Though we would have to do this on multiple interfaces. Here is a list (complete, I think) off all SQLite interfaces that can be called "first" and would thus need to have the test you propose: sqlite3_auto_extension sqlite3_complete sqlite3_complete16 sqlite3_enable_load_extension sqlite3_enable_shared_cache sqlite3_global_recover sqlite3_libversion sqlite3_libversion_number sqlite3_load_extension sqlite3_malloc sqlite3_memory_alarm sqlite3_memory_highwater sqlite3_memory_used sqlite3_mprintf sqlite3_mutex_alloc sqlite3_open sqlite3_open16 sqlite3_open_v2 sqlite3_realloc sqlite3_release_memory sqlite3_reset_auto_extension sqlite3_sleep sqlite3_snprintf sqlite3_soft_heap_limit sqlite3_thread_cleanup sqlite3_threadsafe sqlite3_vfs_find sqlite3_vfs_register sqlite3_vfs_unregister sqlite3_vmprintf -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Proposed sqlite3_initialize() interface
> -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] -
Re: [sqlite] Proposed sqlite3_initialize() interface
I always create and XXX_Initialize() (and also XXX_Finalize() for resources cleanup) in all libraries I created, because: - You can perform initializations that cannot be done at compile time; - You can create your internal structures in the required order (C++ has the problem of initialization / finalization order of static objects, that could be a pain in some cases), independing on compiler / link order of your object files; Putting a simple call to a sqlite3_initialize() in a program costs near to nothing in my point of view, and could make things simpler for sqlite3 library. On Oct 30, 2007 12:18 PM, <[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] > > - > >
