On Fri, May 26, 2017 at 7:33 AM Simon Slavin <slav...@bigfraud.org> wrote:
> > On 26 May 2017, at 6:00am, Wout Mertens <wout.mert...@gmail.com> wrote: > > > Ideally there'd be some way to know if a _step() call will be served from > > buffer… > > There are (simplified) three possibilities: quick quick, slow slow, and > slow quick. > [...] Aha, good to know, thanks! I can’t speak to how useful it will be to handle _step() synchronously in > real life applications. Most of my applications are web-facing systems and > handle their SQLite databases asynchronously because that’s how server > access works in JS. They make HTTP calls to a PHP application running on a > server. But for SELECT commands there’s really little they can do until > they’ve got the first line back and know whether there are any rows. Maybe > prepare a few DOM structures for the results, but that doesn’t take long. > The reason better-sqlite3 calls sqlite in the main thread is that there is a substantial cost to running the DB query in a different thread, involving double copying and mutexes. For small databases, that overhead can really add up, especially if the whole db fits in cache. In my case however, my app runs web services as well as biggish database access in a single process, so I can't block for potentially hundreds of ms. I do like the simplicity of the library, so I'd like it to be minimally asynchronous. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
