Are worker threads green?

[shivam-tripathi]

From what I understood after reading some of really helpful articles by Mayank, Deno internally uses green threads to carry out async tasks (which I assume are I/O tasks).

But it's not immediately clear if worker threads are internally green threads or internally backed by native threads. From my very limited understanding after reading the spec - it isn't explicitly specified how worker threads should be implemented internally. Having ability to spawn green threads which communicate via message passing to me personally sounds like a great idea.

[bartlomieju]

There's a chapter in the manual that explains this topic: https://deno.land/manual@v1.17.0/runtime/workers

The gist is that each worker gets a dedicated OS thread, they do not use green threads.

[andreubotella]

The entire point of workers is that they can run in parallel to the main thread, so you can do intensive computations in a worker without preventing the main thread from making progress. This, in general, is not possible with green threads unless you implement some mechanism for interrupting, which from my limited understanding doesn't seem possible to do with V8, and which is probably enough complexity that it might not be a significant improvement over system threads.

But in the specs, the main thread and the worker are two agents on the same agent cluster. The JS spec says that an "executing thread" (a term which is not defined in the spec, but they mean a system thread) can be shared by multiple agents, as long as their [CanBlock] property is false. And [CanBlock] must be true if an agent can block pending for I/O. So, since Deno provides blocking ("sync") I/O operations on both the main thread and on workers, they must run on separate system threads.

(Now, the [CanBlock] property is meant for the main threads of different same-origin pages in browsers, which must run on a single system thread because they have shared synchronous state. But the main thread in the browser does have one blocking I/O operation, synchronous XHR. That is deprecated and not recommended at all, but it still exists, so the spec's requirements on this aren't really followed to the letter because of legacy code that must still be supported. Note that newer blocking APIs, like Atomics.wait() don't work on the browser's main thread because of this.)