Klemens Friedl wrote:
2007/8/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
I think you will be much much better off to put every
thread it is own private address space. In other words,
turn each thread into a separate process. Threads are
an invention of the devil. Stay as far away from
2007/8/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> I think you will be much much better off to put every
> thread it is own private address space. In other words,
> turn each thread into a separate process. Threads are
> an invention of the devil. Stay as far away from these
> fiendish
--- [EMAIL PROTECTED] wrote:
> =?ISO-8859-1?Q?Daniel_=D6nnerby?= <[EMAIL PROTECTED]> wrote:
> >
> > The new multithread-features will be great.
> > Do you think that it will be better to share one connection between all
> > theads in an application or is better to have each thread open a new
>
D R H said: >>Threads are an invention of the devil.<<
I rather think human beings were to blame; but they had probably read a lot
about the Spanish Inquisition.
Stay as far away from these fiendish abominations as you can get.<<
That's the best bit of programming advice on threads I have
=?ISO-8859-1?Q?Daniel_=D6nnerby?= <[EMAIL PROTECTED]> wrote:
>
> The new multithread-features will be great.
> Do you think that it will be better to share one connection between all
> theads in an application or is better to have each thread open a new
> connection and use the
Hi!
The new multithread-features will be great.
Do you think that it will be better to share one connection between all
theads in an application or is better to have each thread open a new
connection and use the sqlite3_enable_shared_cache?
Best regards
Daniel
[EMAIL PROTECTED] wrote:
The
Would this be a good time to replace the older sqlite3_prepare() and
sqlite3_prepare16() interfaces with what is currently the newer
sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces respectively?
Admittedly they are definitely not among the "less frequently used
interfaces", but such
Dennis Cote <[EMAIL PROTECTED]> wrote:
>
> I wonder if it might not be better to change this API to accept an empty
> string, in addition to a NULL pointer, to find the default VFS. It seems
> to me this might make life easier for those writing wrappers in
> languages that don't have a concept
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> > sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);
> >
> >
> > The argument is the symbolic name for the desired VFS. If the argument
> > is a NULL pointer, then the default VFS is returned. The function
> > returns a pointer to the
On Aug 28, 2007, at 4:51 PM, Dennis Cote wrote:
I wonder if it might not be better to change this API to accept an
empty string, in addition to a NULL pointer, to find the default
VFS. It seems to me this might make life easier for those writing
wrappers in languages that don't have a
The "sqlite3_exec" function has resided in the "legacy.c" file since
shift to version 3. The function is still around in current v3.5 draft
as http://www.sqlite.org/capi350ref.html says.
That function is still kept around for compatibility reasons, as it
was a important function in SQLite v2
[EMAIL PROTECTED] wrote:
The transition from 3.4.2 to 3.5.0 will perhaps be the
largest single change to SQLite since 2.8->3.0.
I have *started* to prepare documentation describing
the changes in 3.5.0. This is draft documentation.
But for those who are interested, please visit
--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- [EMAIL PROTECTED] wrote:
> > > The transition from 3.4.2 to 3.5.0 will perhaps be the
> >
> > > The SQLite code currently in CVS HEAD is not ready for
> > > production use. We know that. We know what many of the
>
Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> > The transition from 3.4.2 to 3.5.0 will perhaps be the
>
> > The SQLite code currently in CVS HEAD is not ready for
> > production use. We know that. We know what many of the
> > problems are and Dan and I are working
--- [EMAIL PROTECTED] wrote:
> The transition from 3.4.2 to 3.5.0 will perhaps be the
...
> The SQLite code currently in CVS HEAD is not ready for
> production use. We know that. We know what many of the
> problems are and Dan and I are working long hours to fix
> them. It's the problems that
Richard Klein <[EMAIL PROTECTED]> wrote:
> The documentation looks great! I look forward to the
> release of 3.5.0.
>
> A couple of questions:
>
> (1) In 3.5.0, a database cache can be shared by two
> different threads having two different database
> connections. I infer from this that two
ranlib .libs/libsqlite3.a
creating libsqlite3.la
(cd .libs && rm -f libsqlite3.la && ln -s ../libsqlite3.la libsqlite3.la)
./libtool --mode=link gcc -g -O2 -I. -I../src -DNDEBUG -DTHREADSAFE=1
-DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1
-DHAVE_READLINE=1
The documentation looks great! I look forward to the
release of 3.5.0.
A couple of questions:
(1) In 3.5.0, a database cache can be shared by two
different threads having two different database
connections. I infer from this that two different
threads can now share a cache without having to
The transition from 3.4.2 to 3.5.0 will perhaps be the
largest single change to SQLite since 2.8->3.0. There
will not be that many visible changes, but a lot is
changing behind the scenes. Some less frequently used
interfaces will be changing in slightly incompatible
ways. Users who have
19 matches
Mail list logo
