Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Btw, I still see one problem of official SQLite solution — it requires COOP to use

Only for the OPFS support, because any solution involving hiding an asynchronous API (OPFS) behind a synchronous one (sqlite) requires it because the "await" keyword in JS is "viral": it can only be used from global-scope code or from functions which are themselves flagged as "async", and flagging a function as "async" changes its return semantics in ways which are fundamentally incompatible with C code. Any solution to that problem in JS requires SharedArrayBuffer and the Atomics APIs. WASMFS's OPFS implementation has the same limitation, despite being implemented in native code.

(That said: there is some talk among those who know better than i of modifying WASM to be able to accept Promises as return values, and returning the resolved promise value to C. i don't think it's possible because promise _rejection_ cannot pass through C code, but folks who know better than i seem to think it can be done.)

If you don't need OPFS support you don't need COOP/COEP. (Citation: i'm the sqlite js/wasm developer and have had this discussion with Google's OPFS folks.)



Yep, yep, I understand the reasons. That's why in where I work we decided to use asyncify because COOP is very strict for us It has a penalty on cold start, but once many blocks cached it works perfectly, without event loop interruptions


> ... COOP is very strict for us

You're not the only one :/. We suspect that the COOP/COEP requirement for OPFS will be outright untenable for many folks, in particular those using hosting which does not offer them the option of modifying outbound headers (in fact, we had to extend sqlite.org's http server, althttpd, to add that capability for this purpose!). We've brought this pain point to the OPFS folks' attention but there is currently simply no way around it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: