Hello, SQLite 3.0 concurrency was greatly improved via multi lock states. Despite this, some stuff seems, to me, quite inappropriate. Busy handler is the "sure" way to avoid deadlocks; But on heavily multi threaded systems, you are forced to determine an acceptable latency time to avoid many context switches due to repeatitive try/sleep periods. Lots of cycles are lost here... and you don't know which waiting request will be served first. Of course, you can build a layer around SQLite to "over" lock transactions... to be relatively sure that no other thread will try to access the ressource in the same time... In this case, you bypass the multi locking state feature of 3.0 but you can gain a FIFO stack around each db access.
SQLite knows when a db is "RESERVED" locked or unlocked. Adding a handler, like the busy one, which could inform when a (void*) is locked or unlocked could be great; Allowing to manage cond signals on the busy stack of many waiting (sqlite*). This could allow to manage fine tuned policies on request priority like some RT systems need. Is this sound crazy? :) Or is there another way to manage this without featuring SQLite? Thanks, bye. -- Guillaume FOUGNIES
