> Is the idea to start with the single-threaded runtime and extend it with
multithreaded support later, or are these runtime architectures mutually
incompatible?
Tokio directly branches the runtime on the single-thread / multi-thread
usage scenarios ("flavors"), so that these separate features can largely be
considered orthogonal. I am only really able to dedicate work to the
single-threaded runtime here currently, so perhaps someone else can pick up
the multi-threaded work after (it may well not be that difficult).
> Given that Rust coroutines are stackless, how would JSPI enter the
picture?
It exactly doesn't have to, unless there truly is blocking IO.
> More generally, what is the envisioned story for the interaction between
(sync/async) Rust and (sync/async) JS? Will async Rust be able to freely
call async JS? What will the relationship be between the JS event loop /
microtask queue and the Tokio runtime?
The hosted event loop concept is to have a budged drive() call that is able
to cooperate with the JS event loop. async Rust -> async JS works fine
without JSPI, only sync Rust -> async JS (e.g. when using block_on) is the
issue which is an error without JSPI and with JSPI can still be supported.
The epoll loop in this hosted runtime remains non-blocking.
I currently just have the single-threaded prototype supporting async libc
calls, I'm looking to see if I can support this both with and without JSPI
as a configuration, which is useful to e.g. `#[tokio::test]` which needs to
run everything synchronously from a Rust perspective. Will see if this
works out fully yet.
Please feel free to hop in on the related Tokio thread as well as that gets
worked through, and I can also share the PR here when it's eventually ready.
On Tue, Jun 9, 2026 at 11:39 AM 'Thomas Lively' via emscripten-discuss <
[email protected]> wrote:
> Sounds like a great idea. I have some questions to make sure I understand
> the plan.
>
> Given that Rust coroutines are stackless, how would JSPI enter the picture?
>
> More generally, what is the envisioned story for the interaction between
> (sync/async) Rust and (sync/async) JS? Will async Rust be able to freely
> call async JS? What will the relationship be between the JS event loop /
> microtask queue and the Tokio runtime?
>
> Is the idea to start with the single-threaded runtime and extend it with
> multithreaded support later, or are these runtime architectures mutually
> incompatible?
>
> On Tue, Jun 9, 2026 at 11:05 AM 'Sam Clegg' via emscripten-discuss <
> [email protected]> wrote:
>
>> This sounds really promising, especially with JSPI becoming more
>> widespread (in emscripten we also have ASYNCIFY which be substituted for
>> JSPI too, in most cases).
>>
>> I don't know much about Rust or Tokio myself, so I cannot offer much
>> guidance, but wonder if it would be good idea (once its ready) to add some
>> basic tests to emscripten test suite (like we have for Rust itself), to
>> make sure don't break this support as we evolve emscripten?
>>
>> cheers,
>> sam
>>
>>
>>
>>
>> On Tue, Jun 9, 2026 at 10:04 AM 'Guy Bedford' via emscripten-discuss <
>> [email protected]> wrote:
>>
>>> Hi all,
>>>
>>> We recently landed support for the Emscripten target in the wasm-bindgen
>>> project and are exploring its adoption more widely for its benefits over
>>> the wasm32-unknown-unknown platform agnostic target, in allowing better
>>> libc compatibility.
>>>
>>> In the Rust ecosystem, Tokio is an async runtime that supports various
>>> targets including only the WASI targets for Wasm, but it does not yet have
>>> full support for the Emscripten Wasm target.
>>>
>>> This means that when building Rust projects for the Emscripten target,
>>> applications using Tokio async features will likely not build correctly.
>>>
>>> There are perhaps two main runtime variations that can work for
>>> Emscripten on Tokio here - a "hosted event loop" single-threaded runtime,
>>> with or without a JSPI switch, and a comprehensive multi-threaded runtime.
>>>
>>> I have been fleshing out the first and simplest single-threaded hosted
>>> event loop model in
>>> https://gist.github.com/guybedford/9f534c70dd4b450294bf27eed139153f,
>>> and also have a draft Emscripten prototype that is able to get the test
>>> suite including many of the net tests passing.
>>>
>>> Towards a formal PR I have opened an initial discussion issue on the
>>> Tokio repo in https://github.com/tokio-rs/tokio/issues/8194.
>>>
>>> The Tokio maintainers seem open to this Emscripten target support, under
>>> the condition that there are clear maintainers for this target in Tokio.
>>> Currently myself, Hood Chatham and Ingvar Stepanyan would be able to take
>>> on this role.
>>>
>>> I'm sharing this topic for any further feedback from the Emscripten
>>> maintainers and community on the design here and also to seek further
>>> collaborators that may be interested in reviewing and assisting with the
>>> maintenance of this target work, either formally or informally.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/eee88b87-565b-463e-a473-02b2a6a0420an%40googlegroups.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/eee88b87-565b-463e-a473-02b2a6a0420an%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-WshTBM%3DJgRDr%2Bh_8n2yGFMxqUfzvyRGCuEL29TitBmQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-WshTBM%3DJgRDr%2Bh_8n2yGFMxqUfzvyRGCuEL29TitBmQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVSx%2Bmstj514%2BCWPpzJDivaPYnORF5DteQnSH1O6BW8uA%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVSx%2Bmstj514%2BCWPpzJDivaPYnORF5DteQnSH1O6BW8uA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/emscripten-discuss/CAM79cYWsytFFPU%2Bm%2BOGh9gQbDJSRQf8Dde5esih5xJznKz6uBg%40mail.gmail.com.
