> Remember, that the operating system bug that is causing all the
> multithreading grief is that file locks created by one thread
> cannot be reliably removed or modified by a different thread.
> So if a statement acquires a lock on the database file in one
> thread and you try to finalize the stat
Joe Wilson <[EMAIL PROTECTED]> wrote:
> Let's assume that for a given OS that fcntl() file locks
> work perfectly well on any thread. Would it then be safe
> from an SQLite perspective to finalize statements that were
> prepared in one thread in a different thread? (where the sqlite
> connection
--- Joe Wilson <[EMAIL PROTECTED]> wrote:
> Let's assume that for a given OS that fcntl() file locks
> work perfectly well on any thread. Would it then be safe
> from an SQLite perspective to finalize statements that were
> prepared in one thread in a different thread? (where the sqlite
> connect
Let's assume that for a given OS that fcntl() file locks
work perfectly well on any thread. Would it then be safe
from an SQLite perspective to finalize statements that were
prepared in one thread in a different thread? (where the sqlite
connection would only be used on one thread at a time).
--
m: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 03, 2006 8:14 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multithreading. Again.
Joe Wilson wrote:
Remember, that the operating system bug that is causing all the
multithreading grief is that file locks created by one th
Doug Nebeker wrote:
> The problem with that solution is that it assumes all database access
> happens from within a single process. As far as I understand it, SQLite
> allows database access from multiple processes (and even from remote
> processes I assume) and thus the locking has to happen outs
t: Re: [sqlite] Multithreading. Again.
Joe Wilson wrote:
>>Remember, that the operating system bug that is causing all the
>>multithreading grief is that file locks created by one thread cannot
>>be reliably removed or modified by a different thread.
>
>
> You
Joe Wilson wrote:
Remember, that the operating system bug that is causing all the
multithreading grief is that file locks created by one thread
cannot be reliably removed or modified by a different thread.
You could have a single thread that exclusively performs file locking/unlocking.
This th
> Remember, that the operating system bug that is causing all the
> multithreading grief is that file locks created by one thread
> cannot be reliably removed or modified by a different thread.
You could have a single thread that exclusively performs file locking/unlocking.
This thread would wait
Florian Weimer <[EMAIL PROTECTED]> wrote:
> > As long as no prepared statements are outstanding, you should
> > be safe moving sqlite database connections across threads, as
> > of version 3.3.1. The rules are not really quite that strict,
> > but the exact rules are more complex and this strict r
a finally block. In c++, I do it using a stack based destructor
guard.
Pat
-Original Message-
From: Florian Weimer [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 9:19 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multithreading. Again.
> As long as no prepared s
> As long as no prepared statements are outstanding, you should
> be safe moving sqlite database connections across threads, as
> of version 3.3.1. The rules are not really quite that strict,
> but the exact rules are more complex and this strict rule
> gives you an extra margin of safety.
Is it
"Peter Cunderlik" <[EMAIL PROTECTED]> wrote:
> > > 1. As of SQLite 3.3.5, there is no multithreading (MT) problem with
> > > the SQLite itself. All problems come from the underlying OS libraries.
> >
> > I would argue that this has always been the case. But beginning
> > in version 3.3.1, SQLite h
> 1. As of SQLite 3.3.5, there is no multithreading (MT) problem with
> the SQLite itself. All problems come from the underlying OS libraries.
I would argue that this has always been the case. But beginning
in version 3.3.1, SQLite has taken additional steps to partially
work around problems in
IL PROTECTED]
Subject: Re: [sqlite] Multithreading. Again.
"Peter Cunderlik" <[EMAIL PROTECTED]> wrote:
> Hello everybody,
>
> I'd like to ask a couple of silly questions before newcomers like me
> get moderated. :-) I've browsed through the documentation and this
"Peter Cunderlik" <[EMAIL PROTECTED]> wrote:
> Hello everybody,
>
> I'd like to ask a couple of silly questions before newcomers like me
> get moderated. :-) I've browsed through the documentation and this
> mailing list, trying to understand issues with multithreading. I'd
> like if someone could
Hello everybody,
I'd like to ask a couple of silly questions before newcomers like me
get moderated. :-) I've browsed through the documentation and this
mailing list, trying to understand issues with multithreading. I'd
like if someone could confirm my conclusions.
1. As of SQLite 3.3.5, there i
17 matches
Mail list logo
