On 9/5/05, Ian Monroe <[EMAIL PROTECTED]> wrote:
>
> >
> > SQLite has *never* supported the ability of a handle to be used
> > by more than one thread. By luck, such use would sometimes work on
> > some operating systems. But it would fail on others. Such a
> > situation is very dangerous since if
Ian Monroe wrote:
I see your just ignorant of how open source software gets released.
Ian,
You are right, I hope you will forgive my ignorance. Beyond that, it
wasn't my place to criticize those projects even if I had fully
understood the situation.
--kiel
,
please don't!
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 05, 2005 9:19 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Problems with threadsafe opt correction #2623
>
> On Mon, 2005-09-05 at 19:
On Mon, 2005-09-05 at 19:58 +0200, René Tegel wrote:
> As far as i can tell now the windows version of 3.2.5 seems not affected.
>
The restriction that a DB handle can only be used from a single
thread is currently only enforced on Unix, because Unix boxes
are the only place where using DB handl
Miha Vrhovnik wrote:
So what does that mean.
On windows I'm protecting database handle with MREWS.
Should I rewrite about 10.000 lines of code. And Check other 30.000. To fix that?
As far as i can tell now the windows version of 3.2.5 seems not affected.
For other os maybe you can extend yo
On 9/5/05, Tobias Rundström <[EMAIL PROTECTED]> wrote:
> Kiel W. wrote:
> > Ian Monroe wrote:
> >
> >> I do not see how such a major change can be justified in a minor point
> >> release. For instance, currently amaroK does not work when using a
> >> sqlite database on Debian Sid since they package
On Mon, 2005-09-05 at 19:23 +0200, Tobias Rundström wrote:
> Well in this case it broke all the currently installed applications that
> was installed and where MISSUSING the API. We have corrected this now
> but it will take a while before we can make a release out of it. In the
> meantime distr
On 9/5/05, Kiel W. <[EMAIL PROTECTED]> wrote:
> Ian Monroe wrote:
>
> >I do not see how such a major change can be justified in a minor point
> >release. For instance, currently amaroK does not work when using a
> >sqlite database on Debian Sid since they package it with sqlite 3.2.5.
> >
> >
> Ju
"D. Richard Hipp" <[EMAIL PROTECTED]> je ob 5.9.2005 18:45:42 napisal(a):
>SQLite has *never* supported the ability of a handle to be used
>by more than one thread. By luck, such use would sometimes work on
>some operating systems. But it would fail on others. Such a
>situation is very dangerou
Kiel W. wrote:
Ian Monroe wrote:
I do not see how such a major change can be justified in a minor point
release. For instance, currently amaroK does not work when using a
sqlite database on Debian Sid since they package it with sqlite 3.2.5.
Just my two cents, but if this change is breaking
Mon, Sep 05, 2005 at 12:45:42PM -0400: D. Richard Hipp wrote:
> On Mon, 2005-09-05 at 10:57 -0500, Ian Monroe wrote:
> > I do not see how such a major change can be justified in a minor point
> > release. For instance, currently amaroK does not work when using a
> > sqlite database on Debian Sid si
René Tegel wrote:
this does only affect linux?
Forgive me that i said linux where i ment unix...
On 9/5/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-09-05 at 10:57 -0500, Ian Monroe wrote:
> > I do not see how such a major change can be justified in a minor point
> > release. For instance, currently amaroK does not work when using a
> > sqlite database on Debian Sid since they
D. Richard Hipp wrote:
This is not a design change. This is not an API change.
It does not break backwards compatibility. All that changed
is that certain errors in the way SQLite is used are now
detected sooner rather than later.
May be you can add some pragma to disable this check?
Also, i
Ian Monroe wrote:
I do not see how such a major change can be justified in a minor point
release. For instance, currently amaroK does not work when using a
sqlite database on Debian Sid since they package it with sqlite 3.2.5.
Just my two cents, but if this change is breaking things in amaroK
On Mon, 2005-09-05 at 18:36 +0200, Tobias Rundström wrote:
> How "expensive" is it to open a new sqlite3 handler?
The schema has to be read and parsed. Usually that is very
quick - SQLite has an efficient parser and can process
tens of thousands of SQL statements per second.
> This seems to occ
On Mon, 2005-09-05 at 10:57 -0500, Ian Monroe wrote:
> I do not see how such a major change can be justified in a minor point
> release. For instance, currently amaroK does not work when using a
> sqlite database on Debian Sid since they package it with sqlite 3.2.5.
>
> Shouldn't this have waited
Ian Monroe wrote:
I do not see how such a major change can be justified in a minor point
release. For instance, currently amaroK does not work when using a
sqlite database on Debian Sid since they package it with sqlite 3.2.5.
Shouldn't this have waited for 4.0?
I agree,
XMMS2 also stoped wor
I do not see how such a major change can be justified in a minor point
release. For instance, currently amaroK does not work when using a
sqlite database on Debian Sid since they package it with sqlite 3.2.5.
Shouldn't this have waited for 4.0?
On Wed, 31 Aug 2005 05:38:05 -0700 D. Richard Hipp w
> This works on some systems but not on others. On some
> versions of Linux, a thread is not able to override locks
> created by a different thread in the same process. When
> that happens, a database connection created on one thread
> will not be usable by a different thread.
This is not the po
Hello,
Is this the only reason for the...
"database handle can only be used on the same thread
that opened it"
...rule? Does Windows have that issue?
If so, can we convert this to a compile time option?
Eg. OS_SUPPORTS_THREADSAFE_FILE_LOCKS or similar
flag which can be set to true for OSes whi
On Wed, 2005-08-31 at 12:53 +0200, Guillaume Fougnies wrote:
> My code is sharing a pool of SQLite connections on
> multiple databases between a bunch of treatment
> threads.
> Each thread pops a connection from the pool safely
> and push it back once finished.
>
This works on some systems but no
22 matches
Mail list logo