On Tue, Sep 06, 2005 at 04:33:32PM +0200, Florian Weimer wrote:
> * Francesco P. Lovergine:
>
> >> I've looked at the SQLite code and it does this. At the same time, it
> >> has to implement recursive locks (which can be entered multiple times
> >> by the same locker, hence it embeds a locker ID
* Francesco P. Lovergine:
>> I've looked at the SQLite code and it does this. At the same time, it
>> has to implement recursive locks (which can be entered multiple times
>> by the same locker, hence it embeds a locker ID (the value returned by
>> phtread_self) in the lock data structure. This
On Tue, Sep 06, 2005 at 11:35:50AM +0200, Florian Weimer wrote:
> * Francesco P. Lovergine:
>
> >> SQLite databases (and Subversion repositories) are intended to be
> >> opened concurrently by multiple processes.
>
> > To be more clear: programs which use ordinary file locking to
> > syncronize t
* Francesco P. Lovergine:
>> SQLite databases (and Subversion repositories) are intended to be
>> opened concurrently by multiple processes.
> To be more clear: programs which use ordinary file locking to
> syncronize threads need to be fixed.
I've looked at the SQLite code and it does this. At
On Mon, Sep 05, 2005 at 03:34:42PM +0200, Florian Weimer wrote:
> * Francesco P. Lovergine:
>
> >> I intended to write the opposite: file locks are a per-process
> >> resource in NPTL, so NPTL probably has the problems, and LinuxThreads
> >> doesn't.
> >
> > A question: why using file locking inst
On Mon, Sep 05, 2005 at 03:42:54PM +0200, Francesco P. Lovergine wrote:
> On Mon, Sep 05, 2005 at 03:34:42PM +0200, Florian Weimer wrote:
> > * Francesco P. Lovergine:
> >
> > >> I intended to write the opposite: file locks are a per-process
> > >> resource in NPTL, so NPTL probably has the proble
On Mon, Sep 05, 2005 at 03:34:42PM +0200, Florian Weimer wrote:
> * Francesco P. Lovergine:
>
> >> I intended to write the opposite: file locks are a per-process
> >> resource in NPTL, so NPTL probably has the problems, and LinuxThreads
> >> doesn't.
> >
> > A question: why using file locking inst
* Francesco P. Lovergine:
>> I intended to write the opposite: file locks are a per-process
>> resource in NPTL, so NPTL probably has the problems, and LinuxThreads
>> doesn't.
>
> A question: why using file locking instead of thread mutexes (which
> is the proper answer to syncronization issues i
On Sun, Sep 04, 2005 at 10:07:56PM +0200, Florian Weimer wrote:
> * Florian Weimer:
>
> > * Adeodato Simó:
> >
> >> Also, I have no idea what's the case for Debian: "On some versions of
> >> Linux, a thread is not able to override locks created by a different
> >> thread in the same process.
* Florian Weimer:
> * Adeodato Simó:
>
>> Also, I have no idea what's the case for Debian: "On some versions of
>> Linux, a thread is not able to override locks created by a different
>> thread in the same process." Does this depend on the kernel, on libc,
>> or on something else?
>
> This
* Adeodato Simó:
> Also, I have no idea what's the case for Debian: "On some versions of
> Linux, a thread is not able to override locks created by a different
> thread in the same process." Does this depend on the kernel, on libc,
> or on something else?
This is probably the same problem
11 matches
Mail list logo
