Re: Bug#326648: libsqlite3-0: database handles can't be shared among threads any more

["Francesco P. Lovergine" <frankie@debian.org>]

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 (the value returned by
> >> phtread_self) in the lock data structure.  This causes the problem
> >> Adeodato described.
> >> 
> >> I don't know how to better implement locking for SQLite, given the
> >> constraints.
> >> 
> >
> > Wow, you are trying to render thread-safe a non-thread-safe library, man
> > if I did understand right the terms of the problem.
> 
> SQLite is thread-safe.  However, you can't pass database handles from
> one thread to the another.
> 

Nice vision of thread-safety... If you in general need to alloc mutexes to protect 
the db handle (which is obviuously used by almost all the sqllite functions)
well, it's not so thread-safe IMHO. Thread safety should be the rule, not 
the exception. See mysqlclient as example of a true almost-thread-safe
db library. 

> > Two, hints:
> >
> >  - See flockfile() and its sister calls for stdio functions.
> 
> The flockfile family of functions has the same problem:
> 
> | The `funlockfile' function does not return an error status and the
> | behavior of a call for a stream which is not locked by the current
> | thread is undefined.
> 

Uh? A 'stream not locked by the current thread' is legitimate: you have
to use flockfile() before funlockfile() in the same thread. It's a
minimal requirement, isn't it? But it protects against race conditions
among threads.

-- 
Francesco P. Lovergine