Support running async functions in web worker instead of main thread

[rlch]

Is your feature request related to a problem? Please describe.

I'm trying to use https://crates.io/crates/sqlite-wasm-rs with OPFS SAHPool, but it doesn't work as FRB is running async functions in the main Window context, instead of the expected Worker context.

If I understand correctly, async Dart + sync Rust uses the worker pool, but in this context I can't await a function in WASM -- which I need to do for sqlite to init properly.

Describe the solution you'd like

I guess the ability to force an async rust function to run in a web-worker context instead of the async runtime.

Describe alternatives you've considered

• Trying to block the async call in a sync context to force thread pool to be used. Not possible.
• https://github.com/cunarist/tokio-with-wasm

[welcome[bot]]

Hi! Thanks for opening your first issue here! :smile:

[fzyzcjy]

Good point! Firstly I wonder whether we can run sync functions in Rust instead of async, then it is already on the worker thread and do not block main thread. e.g. quickly googled and find https://github.com/rusqlite/rusqlite/issues/827#issuecomment-2634729483, dnk whether useful. Secondly, iirc the current async runtime somehow uses the browser's ability, thus may be nontrivial to be run on web worker. May I know a bit how, without frb and only with vanilla rust wasm, is this library supposed to be used? (e.g. what async runtime is it often used with)

[rlch]

@Spxg is the master here;

But every call to WASM needs to establish connection to SQLite, which (in the context of sync-access OPFS requiring a dedicated worker), means we must call an async install method to get a synchronous filesystem handle to OPFS, so that sqlite can interact with it as the underlying database (?)

• IndexedDB and memory works fine because they can run in any context. They can be initialized asynchronously in main thread and then re-used later.

I don't think the comment helps - I can compile it fine by bundling myself when compiling to WASM.

The core issue is initializing OPFS from a sync function running through a worker, because we can't block_on in async_std on WASM

• Also tried https://github.com/zesterer/pollster

Fundamentally, we can't solve this issue in a sync context without JSPI implemented.

---

Curious if you have any thoughts here about how FRB could/(can?) handle this instead. My immediate thoughts are:

• Allowing async Rust + async Dart to execute in a web worker instead of main thread.
• Custom handler that runs wasm_bindgen_futures::spawn_local within the thread pool. Is this possible?

All a bit over my head!

[fzyzcjy]

Hmm I see. I am still not very sure (too tired recently and my brain do not work now :/), how does the lib work without frb and only with vanilla rust wasm? I am not sure but if it is impossible, then I guess frb cannot help as well...

[rlch]

See here: https://github.com/Spxg/sqlight/blob/master/src/worker/mod.rs

It uses a dedicated worker and https://docs.rs/serde-wasm-bindgen/latest/serde_wasm_bindgen/ to manage de/serialization between the worker thread and main thread.

No worries at all, don't let this take your brain power!

[fzyzcjy]

Thanks! Get it. I have not checked that code in details, btw it seems in frb we do sth a little bit similar -> https://github.com/fzyzcjy/flutter_rust_bridge/blob/master/frb_rust/src/third_party/wasm_bindgen/worker_pool. so a naive question - what happens if we simply use the same approach, i.e. copy-paste that code, and maybe its async fn execute_task is a frb fn and can be called from dart.