> It's more or less what I said, it isn't using real OS threads but it is doing something similar to green threads.
It's not even green threads.
Also, literally on the page you linked:
=== start quote ===
The Worker interface spawns real OS-level threads,
=== end quote ===
[1]
> it doesn't spawn an OS thread but it spawns lightweight (or green or simulated) threads with their own VM.
It spawns an isolated process. Javascript as a language and its runtime cannot support threads. To do "threads" they basically initialise a new instance of JS runtime.
This is not "threading" by any definition. MDN page may call that for the sake of people who end up using it, but these are not:
It's an outside implementation, running processes inside the host, and letting processes communicate using memory-mapped values. 20 years ago no one in their right mind would call this "multithreading in language X". It was "app 1 written in any language is communicating with app 2 written in any language via memory-mapped files". Now people who've never seen anything outside web development call it multithreading.
[1] Fun trivia: original implementation literally used a runtime per worker: https://blog.mozilla.org/luke/2012/01/24/jsruntime-is-now-of... It still uses a CycleCollectedJSRuntime per worker, but I'm too lazy to dig through source code for further details.
> It spawns an isolated process. Javascript as a language and its runtime cannot support threads. To do "threads" they basically initialise a new instance of JS runtime.
Sometimes I need an answer as blunt and direct as that one to understand something, thanks.
Unfortunately, there's also a dearth of tech articles discussing how the many parts of web APIs work, and how they are implemented. High-level articles help with using them, but will always simplify things :)
It's not even green threads.
Also, literally on the page you linked:
=== start quote ===
The Worker interface spawns real OS-level threads,
=== end quote ===
[1]
> it doesn't spawn an OS thread but it spawns lightweight (or green or simulated) threads with their own VM.
It spawns an isolated process. Javascript as a language and its runtime cannot support threads. To do "threads" they basically initialise a new instance of JS runtime.
This is not "threading" by any definition. MDN page may call that for the sake of people who end up using it, but these are not:
- threads
- green threads
- lightweight
If in doubt, you could try and find any implementation of a thread or a worker in the JS VM: https://github.com/mozilla/gecko-dev/tree/master/js/src/vm
It's not there, because workers are implemented at the DOM level, in the browser: https://github.com/mozilla/gecko-dev/tree/master/dom/workers
It's an outside implementation, running processes inside the host, and letting processes communicate using memory-mapped values. 20 years ago no one in their right mind would call this "multithreading in language X". It was "app 1 written in any language is communicating with app 2 written in any language via memory-mapped files". Now people who've never seen anything outside web development call it multithreading.
[1] Fun trivia: original implementation literally used a runtime per worker: https://blog.mozilla.org/luke/2012/01/24/jsruntime-is-now-of... It still uses a CycleCollectedJSRuntime per worker, but I'm too lazy to dig through source code for further details.