5 ms·

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter h

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

b34r 11y ago
Web workers
plaguuuuuu 11y ago
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
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)
tlrobinson 11y ago
There's no reason you can't have multiple "apps" running at the same time, you just don't have preemption ( https://en.wikipedia.org/wiki/Preemption_(computing) https://en.wikipedia.org/wiki/Preemption_(computing) ) so it's possible for one application to tie up the CPU indefinitely. That's definitely not whats happening in this case, since the UI is still responsive. Alternatively, to get true isolation and preemptive multitasking you could have a sort of "window server" that sends UI events to Web Workers and received drawing commands of some kind (a React virtual DOM?)
- spankalee 11y ago
  You don't need web workers, you just need to host each app in a sandboxed iframe. Then it can render however it wants with normal DOM access and have script and DOM isolation from the OS and other apps. You would need some sort of IPC system on top of postMessage, and probably some way to send theme data down into the frame and get things like content sizes back out. I don't think same-origin iframed apps would be out-of-process in Chrome yet, but I do think Chrome is supposed to get out-of-process frames eventually. That would prevent an apps from exploiting a browser bug to take down the whole tab.
geon 11y ago
> If you switch windows the background application stops. > desktop replacement If it replaces the desktop, there is no other window to switch to. The problem would be with apps that block, since all multitasking (excluding web workers, but they can't do UI) must be cooperative.

Too bad browser JS is single-threaded. If you switch windows the background application stops. Kind of limits its ability as a desktop replacement no matter how much effort they put into it.

b34r 11y ago

Web workers

plaguuuuuu 11y ago

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

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)

tlrobinson 11y ago

There's no reason you can't have multiple "apps" running at the same time, you just don't have preemption ( https://en.wikipedia.org/wiki/Preemption_(computing) https://en.wikipedia.org/wiki/Preemption_(computing) ) so it's possible for one application to tie up the CPU indefinitely. That's definitely not whats happening in this case, since the UI is still responsive. Alternatively, to get true isolation and preemptive multitasking you could have a sort of "window server" that sends UI events to Web Workers and received drawing commands of some kind (a React virtual DOM?)

spankalee 11y ago
You don't need web workers, you just need to host each app in a sandboxed iframe. Then it can render however it wants with normal DOM access and have script and DOM isolation from the OS and other apps. You would need some sort of IPC system on top of postMessage, and probably some way to send theme data down into the frame and get things like content sizes back out. I don't think same-origin iframed apps would be out-of-process in Chrome yet, but I do think Chrome is supposed to get out-of-process frames eventually. That would prevent an apps from exploiting a browser bug to take down the whole tab.

geon 11y ago

> If you switch windows the background application stops. > desktop replacement If it replaces the desktop, there is no other window to switch to. The problem would be with apps that block, since all multitasking (excluding web workers, but they can't do UI) must be cooperative.