4 ms·

It certainly looks as if each app lives in its own process of sorts - check the 'process viewer' I'm sure they could use some sort of thread/process implementa

It certainly looks as if each app lives in its own process of sorts - check the 'process viewer' I'm sure they could use some sort of thread/process implementation with a scheduler to do stuff. Speculation, each program could be compiled to some sort of bytecode, use asm.js to implement the guts of the thing, etc. When you think about it, a single-core machine is "single threaded" as well, you just need some interleaving code to let more than 1 thing run at a time, and from some casual usage of the demo, seems they've done exactly that, so there you go

Lerc 11y ago
A single core machine can multi thread, but without a timer interrupt it's hard work. What can JavaScript do to provide an interrupt short of emulating a processor with an interrupt via some form of: while true() { do an instruction; check for interrupt; } It's not an efficient way to go.
- meowface 11y ago
  This is just an event loop, no?
  - Lerc 11y ago
    In a sense it is, and in a way that is the problem with the current model of JavaScript. That line do an instruction; Is the smallest unit of code execution. In JavaScript* that is an event. Let's call it a wibblywoop. JavaScript is effectively designed around the premise that a wibblywoop takes a negligible amount of time. This premise is false. Oftentimes it does take a negligible amount of time, when it doesn't the impact of responsiveness is severe. This is why everything becomes a callback. The language itself has indicators that this should not be the case. the existence of things like Array.Map shows that there was certainly an intention at some point for a function to be able to do a significant workload and return a result. * in implementations anyway. The language itself doesn't seem intrinsically bound to the event model.
- narrator 11y ago
  If you're going to do it that way, then might as well use jslinux[1]. [1]. http://bellard.org/jslinux/ http://bellard.org/jslinux/

Lerc 11y ago

A single core machine can multi thread, but without a timer interrupt it's hard work. What can JavaScript do to provide an interrupt short of emulating a processor with an interrupt via some form of: while true() { do an instruction; check for interrupt; } It's not an efficient way to go.

meowface 11y ago
This is just an event loop, no?
- Lerc 11y ago
  In a sense it is, and in a way that is the problem with the current model of JavaScript. That line do an instruction; Is the smallest unit of code execution. In JavaScript* that is an event. Let's call it a wibblywoop. JavaScript is effectively designed around the premise that a wibblywoop takes a negligible amount of time. This premise is false. Oftentimes it does take a negligible amount of time, when it doesn't the impact of responsiveness is severe. This is why everything becomes a callback. The language itself has indicators that this should not be the case. the existence of things like Array.Map shows that there was certainly an intention at some point for a function to be able to do a significant workload and return a result. * in implementations anyway. The language itself doesn't seem intrinsically bound to the event model.
narrator 11y ago
If you're going to do it that way, then might as well use jslinux[1]. [1]. http://bellard.org/jslinux/ http://bellard.org/jslinux/