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----- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: Saturday, June 03, 2006 8:14 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Multithreading. Again. Joe Wilson wrote: >>Remember, that the operating system bug that is causing all the >>multithreading grief is that file locks created by one thread cannot >>be reliably removed or modified by a different thread. > > > 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. > That sounds like good practice to me. When one discovers that a particular function is flaky and variable between implementations, O/S's and versions prudence requires that it be bypassed. In our Sqlite usage we want platform independence and reliability and accordingly never rely on file locking for synchronization. A bonus of such an approach is simpler code and logic and better execution efficiency. JS To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
