3 ms·

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell? Even the concurrency provided by we

by Lerc 11y ago

What is the reason for requiring the single thread of execution in JavaScript? Trading race conditions for callback hell? Even the concurrency provided by web workers, suffer from the same issues, you communicate with them via messages and they will not respond to messages if they are looping away somewhere else. I'd love to have some simple pre-emption in JavaScript. Suspend code execution at one point and pick it up at another. Instead of having threads, have the fundamentals that allow threads. Has this been discussed and rejected by the JavaScript community? I'd really like to know what the deal is here

desdiv 11y ago
The single thread limitation is caused by the global interpreter lock[0] that's common to most interpreted languages. Along with JS, it also appears in CPython and Ruby MRI, the reference implementation of Python and Ruby respectively. [0] https://en.wikipedia.org/wiki/Global_interpreter_lock https://en.wikipedia.org/wiki/Global_interpreter_lock
- tlrobinson 11y ago
  That's not the reason. As I understand it, the GIL is an implementation detail of certain interpreters that prevents threads from running on multiple OS threads (and thus multiple CPUs). JavaScript has explicitly chosen not to support preemptive multithreading at all (aside from Web Workers which don't share memory), while Ruby and Python do have it, even if it can't fully utilize multicore processors.
- Lerc 11y ago
  That doesn't eliminate the possibility of pre-emption though does it? A theoretical version of setTimeout that triggered immediately suspending the active code and executing the timeout function then resuming (or potentially not). That only requires the interpretor to execute one piece of code at a time. The notions of thread safety would apply to the interpreted code, but not to the interpretor itself.
- vidarh 11y ago
  No, it's not. MRI for example uses OS-level threads from 1.9.x onwards. The GIL prevents multiple of those threads from executing inside the interpreter at any given time, which may sound like it forces a single thread to be running but in practice most typical code will end up spending a lot of time running in C extensions or waiting on kernel space, so it's much less of a hindrance than you might think (it's still not great, but it's far better than it'd be otherwise)
Too 11y ago
I don't understand the limitation you are implying with web workers and message passing? If a normal thread is also "looping away somewhere else" it will be equally unresponsive as as web worker not picking up messages. The alternative to message passing would be shared data structures and mutexes, not very nice.
- Lerc 11y ago
  A pre-emption mechanism would be able receive the message and respond. At the very least a response of "I'm busy" is better than no response that could be for any number of reasons. Shared data structures would enable this, and while you may not think they are very nice, I would prefer a not very nice solution to no solution whatsoever. I have seen discussions on various mailing that indicate that shared data structures will be implemented in some manner. Look at the example number crunching worker given in the spec. https://html.spec.whatwg.org/multipage/workers.html#a-background-number-crunching-worker https://html.spec.whatwg.org/multipage/workers.html#a-backgr... var n = 1; search: while (true) { n += 1; for (var i = 2; i <= Math.sqrt(n); i += 1) if (n % i == 0) continue search; // found a prime! postMessage(n); } How would you implement this worker in such a way that the host page could call worker.postMessage( {"command": "startfrom", "value" : 131071} ); to get the prime calculator change it's search point?
  - geocar 11y ago
    Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.
    - Lerc 11y ago
      I'm not sure I follow the bit about convincing myself. Going back to square one again with a setTimout/event loop renders much of the use of workers pointless, you are stuck back at the same restrictions as main thread JavaScript. I agree pre-emption would allow this without shared data structures. It just seems that the solution we will be given in the end will be a shared model. http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.ht...

by Lerc 11y ago

desdiv 11y ago

The single thread limitation is caused by the global interpreter lock[0] that's common to most interpreted languages. Along with JS, it also appears in CPython and Ruby MRI, the reference implementation of Python and Ruby respectively. [0] https://en.wikipedia.org/wiki/Global_interpreter_lock https://en.wikipedia.org/wiki/Global_interpreter_lock

tlrobinson 11y ago
That's not the reason. As I understand it, the GIL is an implementation detail of certain interpreters that prevents threads from running on multiple OS threads (and thus multiple CPUs). JavaScript has explicitly chosen not to support preemptive multithreading at all (aside from Web Workers which don't share memory), while Ruby and Python do have it, even if it can't fully utilize multicore processors.
Lerc 11y ago
That doesn't eliminate the possibility of pre-emption though does it? A theoretical version of setTimeout that triggered immediately suspending the active code and executing the timeout function then resuming (or potentially not). That only requires the interpretor to execute one piece of code at a time. The notions of thread safety would apply to the interpreted code, but not to the interpretor itself.
vidarh 11y ago
No, it's not. MRI for example uses OS-level threads from 1.9.x onwards. The GIL prevents multiple of those threads from executing inside the interpreter at any given time, which may sound like it forces a single thread to be running but in practice most typical code will end up spending a lot of time running in C extensions or waiting on kernel space, so it's much less of a hindrance than you might think (it's still not great, but it's far better than it'd be otherwise)

Too 11y ago

I don't understand the limitation you are implying with web workers and message passing? If a normal thread is also "looping away somewhere else" it will be equally unresponsive as as web worker not picking up messages. The alternative to message passing would be shared data structures and mutexes, not very nice.

Lerc 11y ago
A pre-emption mechanism would be able receive the message and respond. At the very least a response of "I'm busy" is better than no response that could be for any number of reasons. Shared data structures would enable this, and while you may not think they are very nice, I would prefer a not very nice solution to no solution whatsoever. I have seen discussions on various mailing that indicate that shared data structures will be implemented in some manner. Look at the example number crunching worker given in the spec. https://html.spec.whatwg.org/multipage/workers.html#a-background-number-crunching-worker https://html.spec.whatwg.org/multipage/workers.html#a-backgr... var n = 1; search: while (true) { n += 1; for (var i = 2; i <= Math.sqrt(n); i += 1) if (n % i == 0) continue search; // found a prime! postMessage(n); } How would you implement this worker in such a way that the host page could call worker.postMessage( {"command": "startfrom", "value" : 131071} ); to get the prime calculator change it's search point?
- geocar 11y ago
  Convert the while/for loops and recursion to continuation-passing style and bounce via nextTick/setTimeout to convince yourself that shared data structures still aren't required to fix this: only pre-emption.
  - Lerc 11y ago
    I'm not sure I follow the bit about convincing myself. Going back to square one again with a setTimout/event loop renders much of the use of workers pointless, you are stuck back at the same restrictions as main thread JavaScript. I agree pre-emption would allow this without shared data structures. It just seems that the solution we will be given in the end will be a shared model. http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.ht...