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 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 threads need to be fixed.
> 
> 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.

Two, hints:

 - See flockfile() and its sister calls for stdio functions.
 
 - You should add a 'big lock' (based on a single condition variable) 
   entering thread functions which have to have write-access to the per-process 
   locked file (the db itself I suspect?). That would avoid race conditions
   for non thread-safe code like that. This is not easy, and it would 
   also impact performances. More granularity (i.e. more condition
   variables to mutex subgroups of functions) you will able to get,
   more performaces you will gain. BUT, more granularity could seriously 
   create hidden synchronization problems and deadlocks among threads. 

   This is the standard approach to call non-thread-safe legacy libraries
   within a multi-thread program, briefly. But it's not like a walking in the
   park... 

-- 
Francesco P. Lovergine