4 ms·

The fundamental problem sounds like it's that SQLite insists on not running in its own thread. This, coupled with the fact that Linux has no way to issue a tru

The fundamental problem sounds like it's that SQLite insists on not running in its own thread. This, coupled with the fact that Linux has no way to issue a true (i.e., non-blocking) write barrier, means that there is no way to implement write barriers in user space. Whereas, if SQLite did issue I/O from a separate thread, one could easily implement an "async commit" function which guaranteed consistency and ordering but not necessarily durability (i.e. a write barrier). This would suffice I suspect for 95% of usage in applications: users will probably be OK if their phone loses the last few seconds of user input before an OS crash, so long as everything else is left intact. EDIT: In fact, Postgresql has an option to permit exactly this behavior: https://www.postgresql.org/docs/9.6/static/wal-async-commit.html https://www.postgresql.org/docs/9.6/static/wal-async-commit.... This is possible in Postgresql because, unlike SQLite, I/O does not run in the client thread.

swift 10y ago
It is possible to run SQLite entirely on a separate thread and avoid blocking the main thread on its I/O, though. It just requires that you're willing to ship the data you need to read and write between threads and handle the synchronization yourself. I've written applications that do this and it works very well, but it's certainly more work than if SQLite supported off-main-thread I/O natively.
- colanderman 10y ago
  Of course. But that's more work that I bet 95% of app developers are willing/able to put in. (Heck I've been doing this stuff for years and still have to spend time analyzing my code to make sure I'm not inadvertently holding locks in places where I shouldn't be.)
kllrnohj 10y ago
> The fundamental problem sounds like it's that SQLite insists on not running in its own thread. Pretty much all apps DO have SQLite running on its own thread, or at least a background thread pool of some sort. Android gets very cranky at the developer if they don't do this - there's tons of warnings, both runtime and in the form of lint. Database access, or anything involving fsync(), is exceptionally rare on the UI thread or any user-latency-critical thread.

swift 10y ago

It is possible to run SQLite entirely on a separate thread and avoid blocking the main thread on its I/O, though. It just requires that you're willing to ship the data you need to read and write between threads and handle the synchronization yourself. I've written applications that do this and it works very well, but it's certainly more work than if SQLite supported off-main-thread I/O natively.

colanderman 10y ago
Of course. But that's more work that I bet 95% of app developers are willing/able to put in. (Heck I've been doing this stuff for years and still have to spend time analyzing my code to make sure I'm not inadvertently holding locks in places where I shouldn't be.)

kllrnohj 10y ago

> The fundamental problem sounds like it's that SQLite insists on not running in its own thread. Pretty much all apps DO have SQLite running on its own thread, or at least a background thread pool of some sort. Android gets very cranky at the developer if they don't do this - there's tons of warnings, both runtime and in the form of lint. Database access, or anything involving fsync(), is exceptionally rare on the UI thread or any user-latency-critical thread.