On Tue, 15 Jan 2019 at 02:54, Simon Slavin <slav...@bigfraud.org> wrote:
> The "just-in-time" idea mentioned in your question doesn't work in real > life, since constantly checking mutex status keeps one core completely > busy, using lots of power and generating lots of heat. > Technically "just-in-time" could be implemented fine; the normal file locking primitives used on both windows and unix can operate in a blocking mode, where the kernel wakes the process up once the lock has been relinquished. sqlite just doesn't use that API. It would be a pretty significant change for sqlite to invoke said API, and may affect the ability to support other existing locking modes which don't provide the same semantics and where polling _is_ required (eg. dotfile). Also I'm not 100% sure whether it would be safe to drop in, or whether blocking the process for lock acquisition within sqlite's locking protocol would introduce deadlock scenarios. FYI sqlite's backoff reaches a maximum sleep time of 100ms. Unless you're on unix and compile without -DHAVE_USLEEP=1 in which case there's no backoff and every sleep is 1000ms long. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
