Re: Bug#326648: libsqlite3-0: database handles can't be shared among threads any more
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
Wow, you are trying to render thread-safe a non-thread-safe library, man
if I did understand right the terms of the problem.
- 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
Francesco P. Lovergine