Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-06 Thread Jay Sprenkle
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-06 Thread Kiel W.
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

RE: [sqlite] Problems with threadsafe opt correction #2623

2005-09-06 Thread Cariotoglou Mike
, 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:

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread D. Richard Hipp
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread René Tegel
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Ian Monroe
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread D. Richard Hipp
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Ian Monroe
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Miha Vrhovnik
"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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Tobias Rundström
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Guillaume Fougnies
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread René Tegel
René Tegel wrote: this does only affect linux? Forgive me that i said linux where i ment unix...

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Ian Monroe
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread René Tegel
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Kiel W.
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread D. Richard Hipp
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread D. Richard Hipp
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Tobias Rundström
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-09-05 Thread Ian Monroe
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-08-31 Thread Guillaume Fougnies
> 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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-08-31 Thread Kervin L. Pierre
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

Re: [sqlite] Problems with threadsafe opt correction #2623

2005-08-31 Thread D. Richard Hipp
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