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
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
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
-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
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.
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
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
-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
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
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
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
--- 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
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
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
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
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
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
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
[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
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
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
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
22 matches
Mail list logo