Clément Lassieur <[email protected]> skribis: > Ludovic Courtès <[email protected]> writes:
[...] >> Perhaps instead we need to set the timeout to a small value and handle >> SQLITE_BUSY at the call site in our code. We could define a macro that >> automatically retries upon SQLITE_BUSY. > > That would limit the issue to the first timeout span: for that short > time the scheduler would be blocked. I think a timeout of 0 would be > better. Yes, 0 is an acceptable “small value.” ;-) Perhaps 100ms would be acceptable if the situation is rare enough, dunno. > Another solution would be to serialize all the database accesses as we > do already with the url handler, and stop using the SQLITE > multithreading features. It would probably make the code simpler > because we would use the same paradigm everywhere, and we would avoid > looping until SQLITE isn't busy at each request. In essence we’d introduce a “database server” running as a fiber, and everyone would talk to that server. I considered doing that before but then though sqlite would probably be able to do better than this, but I don’t know. What’s a bit annoying with switching to a database server model is that we’d need to adapt every call site. Thoughts? Ludo’.
