Doug Nebeker wrote: > The problem with that solution is that it assumes all database access > happens from within a single process. As far as I understand it, SQLite > allows database access from multiple processes (and even from remote > processes I assume) and thus the locking has to happen outside of the > process. In process locking would be a nice conditionally compiled > optimization, but you'd have to guarantee that no other process would > never touch the database. > > -----Original Message----- > You could have a single thread that exclusively performs file > locking/unlocking. This > thread would wait on a threadsafe work queue (using a POSIX > condition variable mechanism) and execute file locking/unlocking > tasks, otherwise it would use zero CPU. Functions could be provided to > put file lock/unlock operations on to this work queue and wait for > the result. > Such file locking/unlocking functions could be called > safely and reliably from any thread.
I read the original post to mean that the file locking/unlocking was still done, but that it was all done from a single worker thread, so that it was safe to do stuff that requires locks from any thread. Which solves your objection. -- Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming http://www.trumphurst.com/
