5 ms·

Ryan has a vested interest in not having people adopt coroutines since they show that his stupid "events with callbacks are faster and easier than threads" is b

by zedshaw 15y ago

Ryan has a vested interest in not having people adopt coroutines since they show that his stupid "events with callbacks are faster and easier than threads" is bullshit. The truth is if you have coroutines (and these are really easy in unix with C), then you don't need callbacks and you can make an event based system look and work exactly like a thread based system without the shared resource drawbacks. With coroutines you can also do callbacks, so you can get the best of all worlds, which you can't get with pure callbacks only system like Node.js has.

shirro 15y ago
Well to be fair Javascript is kind of limited so Ryan does not have language support for coroutines unless he wants to redesign Javascript. Even better for node.js would be something a bit more CSP-like such as goroutines and channels but again - Javascript. If you want Javascript with coroutines you can always use Lua.
- someone13 15y ago
  And heck, there's even a Node.js-ish library for Lua: https://github.com/luvit/luvit https://github.com/luvit/luvit
  - politician 15y ago
    Tangent: Does anyone know if Node.js on NaCl is possible? exists?
    - wmf 15y ago
      I must be missing something; if you're in the browser you already have JavaScript.
- LeafStorm 15y ago
  Speaking of Lua, it doesn't actually have any language constructs for coroutines - coroutine creation and switching is handled entirely via library functions in the `coroutine` package. So while adding coroutine support to V8 would probably require some substantial internal rewrites, it wouldn't necessitate changing the language - just add a global Coroutine object with the coroutine-switching functions like create, resume, yield...
  - silentbicycle 15y ago
    Right, it just needs a sufficiently powerful C API and internals designed with coroutines in mind. ("just" sounds out of place, there...) If you want to look at the Lua coroutine implementation, start at auxresume (http://www.lua.org/source/5.1/lbaselib.c.html#auxresume http://www.lua.org/source/5.1/lbaselib.c.html#auxresume) in lbaselib.c, and the functions tagged luaB_ more generally. (In 5.2, they've been moved to their own file, lcorolib.c.)
strags 15y ago
Coroutines do impose some overhead - each coroutine still requires its own stack. You either have to allocate a stack big enough for the maximum depth that a coroutine will need (and when you're making complex library calls, that can be pretty deep) - OR - you save memory by assuming that the "suspend" call will only occur when there's relatively little stack space used, in which case you manually save/restore the stack by copying - and hope that the overhead of copying a stack for each context switch isn't a killer. I'm also guessing that it's also not entirely true that there are no shared resource drawbacks. Whenever lthread moves a heavy computation into a pthread, all synchronization bets are presumably off. If you've got two "CPU intensive" workers that reference the same data structures, then you're still going to need mutexes, right?
- halayli 15y ago
  Yes a coroutine user has to be aware that allocating on the stack has a penalty, similar to being aware that you cannot make a blocking call in an IO loop for example. On average, yielding ~10 calls deep results in copying ~75 to 100 bytes but it all depends on what has been on the stack. One advantage in lthread is it's easy to take advantage of cores which isn't very natural in IO loops. Yes you'll need a synchronization mechanism when accessing shared data structures from multiple CPU intensive workers.
  - beagle3 15y ago
    Wait a sec .. I just realized you're copying the entire stack. If I understand correctly, that means that when you move stuff to a compute_lthread, the addresses of local variables change, don't they? I often take addresses of local variables -- if I understood correctly, this deserves a huge warning in the documentation.
    - halayli 15y ago
      Correct. The local variables address change, but you can still access them, and pass them to functions. What you cannot do is save a pointer of a variable and access inside begin()/end(). I thought I added a warning in the lthread_compute_begin() section but apparently not. I'll go ahead and add it.
pjmlp 15y ago
Could not agree more. Node.js is the new fad riding on JavaScript wave. I still don't understand what it brings, when comparing it with more sound alternatives.

by zedshaw 15y ago

shirro 15y ago

Well to be fair Javascript is kind of limited so Ryan does not have language support for coroutines unless he wants to redesign Javascript. Even better for node.js would be something a bit more CSP-like such as goroutines and channels but again - Javascript. If you want Javascript with coroutines you can always use Lua.

someone13 15y ago
And heck, there's even a Node.js-ish library for Lua: https://github.com/luvit/luvit https://github.com/luvit/luvit
- politician 15y ago
  Tangent: Does anyone know if Node.js on NaCl is possible? exists?
  - wmf 15y ago
    I must be missing something; if you're in the browser you already have JavaScript.
LeafStorm 15y ago
Speaking of Lua, it doesn't actually have any language constructs for coroutines - coroutine creation and switching is handled entirely via library functions in the `coroutine` package. So while adding coroutine support to V8 would probably require some substantial internal rewrites, it wouldn't necessitate changing the language - just add a global Coroutine object with the coroutine-switching functions like create, resume, yield...
- silentbicycle 15y ago
  Right, it just needs a sufficiently powerful C API and internals designed with coroutines in mind. ("just" sounds out of place, there...) If you want to look at the Lua coroutine implementation, start at auxresume (http://www.lua.org/source/5.1/lbaselib.c.html#auxresume http://www.lua.org/source/5.1/lbaselib.c.html#auxresume) in lbaselib.c, and the functions tagged luaB_ more generally. (In 5.2, they've been moved to their own file, lcorolib.c.)

strags 15y ago

Coroutines do impose some overhead - each coroutine still requires its own stack. You either have to allocate a stack big enough for the maximum depth that a coroutine will need (and when you're making complex library calls, that can be pretty deep) - OR - you save memory by assuming that the "suspend" call will only occur when there's relatively little stack space used, in which case you manually save/restore the stack by copying - and hope that the overhead of copying a stack for each context switch isn't a killer. I'm also guessing that it's also not entirely true that there are no shared resource drawbacks. Whenever lthread moves a heavy computation into a pthread, all synchronization bets are presumably off. If you've got two "CPU intensive" workers that reference the same data structures, then you're still going to need mutexes, right?

halayli 15y ago
Yes a coroutine user has to be aware that allocating on the stack has a penalty, similar to being aware that you cannot make a blocking call in an IO loop for example. On average, yielding ~10 calls deep results in copying ~75 to 100 bytes but it all depends on what has been on the stack. One advantage in lthread is it's easy to take advantage of cores which isn't very natural in IO loops. Yes you'll need a synchronization mechanism when accessing shared data structures from multiple CPU intensive workers.
- beagle3 15y ago
  Wait a sec .. I just realized you're copying the entire stack. If I understand correctly, that means that when you move stuff to a compute_lthread, the addresses of local variables change, don't they? I often take addresses of local variables -- if I understood correctly, this deserves a huge warning in the documentation.
  - halayli 15y ago
    Correct. The local variables address change, but you can still access them, and pass them to functions. What you cannot do is save a pointer of a variable and access inside begin()/end(). I thought I added a warning in the lthread_compute_begin() section but apparently not. I'll go ahead and add it.

pjmlp 15y ago

Could not agree more. Node.js is the new fad riding on JavaScript wave. I still don't understand what it brings, when comparing it with more sound alternatives.