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