Mapping Web Workers onto Tokio tasks using the multithreaded RT?

[mwcampbell]

Perhaps this has already been discussed elsewhere and I've just missed it, but I wonder if it would be worthwhile to use a single instance of the Tokio multithreaded runtime for all of Deno, and spawn workers as Tokio tasks rather than dedicated threads. Then one could experiment with things like spawning a worker per HTTP request, for increased isolation, without incurring the overhead of an OS thread for each worker.

[bartlomieju]

This is against the spec, which says that each worker should have its own thread. Additionally all of Deno worker infrastructure is written in a way that doesn't allow moving workers (ie. JsRuntime, ie. V8 isolate) across the threads.

[mwcampbell]

Where exactly is that in the spec? On a cursory skim, the only actual references to threads are in non-normative sections.

The inability to move V8 isolates between threads seems like the main issue to me. Is that a limitation of V8 itself, or just Deno?

[bartlomieju]

Where exactly is that in the spec? On a cursory skim, the only actual references to threads are in non-normative sections.

The best I can find is here, in section regarding worklets: https://html.spec.whatwg.org/#worklets-motivations
It says:

Worklets are similar to web workers. However, they:

Are thread-agnostic. That is, they are not designed to run on a dedicated separate thread, like each worker is. Implementations can run worklets wherever they choose (including on the main thread).

The inability to move V8 isolates between threads seems like the main issue to me. Is that a limitation of V8 itself, or just Deno?

When rusty_v8 (the binding layer for V8 engine was created, we dropped Locker API to make it easier to use, there's a PR that adds the Locker API back (denoland/rusty_v8#738), but even then it would be non-trivial to rewrite all code in deno_core and deno_runtime to allow moving workers across threads.

The idea you have is interesting but I'm not sure about the (potential) benefits and additionally I can see a few potential headaches with using multithreaded Tokio runtime (we actually used it in the past, but switched to single threaded runtime + a new runtime for each worker). Given that there's significant engineering effort involved it's not something the core team will be working on.

[andreubotella]

The worker algorithms in the spec specify that creating a worker must create an agent with canBlock set to true. (run a worker algorithm, step 5). Now, the ECMAScript definition for agent specifies that a number of agents can share an execution thread, as long as [[CanBlock]] is false for all of them. Meaning that, for workers, since [[CanBlock]] is true, the thread can't be shared with any other agent.