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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
