> 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
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
>
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).
hn 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 thr
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
: [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
> 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
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 stateme
> 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
> 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
OTECTED]
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
> mailing li
"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
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
17 matches
Mail list logo
