Abort query request with AbortController?

[radames]

Hi @phiresky , thanks for such fantastic and clever project.

Is there anyway I can abort a query request? For example while testing, I wanted to cancel a misfortunate query that would return too many rows and before requesting the whole db I wanted to abort the request.

I'm wondering if would be possible to use AbortController as way to stop the async calls.

[phiresky]

Sadly this won't really be possible without major changes (and an amount of effort I'm not willing to do). The async part of the queries is just transferring the query request to the webworker and transferring the result back. The actual query is completely synchronous within the webworker.

You can stop an SQLite query while it is returning rows by simply stopping to call sqlite3_step (db.exec calls this in a loop). Here it would require a major interface overhaul to support cancelling (including making the exec method async), but it should work.

But you can't stop it while it is fetching data which is probably most of the relevant cases, since that part is synchronous within SQLite core. You can cancel those with sqlite3_interrupt but that only works when threading is enabled in SQLite, which is incompatible with emscripten. The only thing that could work is having a SharedArrayBuffer that can be signalled from the main thread which then throws an Error within the virtual file system functions. But that would make it depend on SharedArrayBuffer, which only works under certain circumstances (https only etc). Also I think throwing an error there destroys the WASM stack and leaves SQLite in an undefined state, which would make it similar to just destroying the whole WebWorker with worker.terminate();

Another alternative would be to make the whole SQLite core async with asyncify, then you can maybe set the interrupted bit in SQLite from the same thread. But asyncify as a whole makes the wasm code much larger and slower. There's some discussion about that here.

I'm happy to hear other solutions, but from what I see there's no good way to do this so I'm closing this as wontfix for now.

[rhashimoto]

Does the Emscripten FS API neither define non-exception errors nor catch exceptions below the POSIX calls? If not, I believe you could still make your SharedArrrayBuffer technique work with a synchronous SQLite VFS returning an error code, which should propagate normally and hopefully leave the SQLite internal state consistent. I skimmed some of the pager code and it looks like it tries to do the right thing.

[phiresky]

That's true, with SharedArrayBuffer it should work. But SharedArrayBuffer is not needed for the rest of the code (except the DOM thing, but that was really just a for-fun thing and is independent of the main httpvfs thing) and I don't want to make the rest depend on it because of the control over HTTP headers you need to make that work, plus the HTTPS requirement and the incompatibilitiy with some browsers.

[phiresky]

I think it would be valid to reimplement my VFS on top of your @rhashimoto wa-sqlite library and add the ability to cancel only if the whole thing is compiled in async mode (then the cancel request can just set a boolean isCancelled flag somewhere).

[TJKoury]

@phiresky Threading is available in emscripten, but my attempts to use it for compiling SQLite have not worked that well, lots of shims required. I might be able to contribute something if / when I get that working.