5 ms·

So, coroutine are as fast as callbacks and easier to program with... so, why aren't available is all language? I understand that it is difficult to change Java

So, coroutine are as fast as callbacks and easier to program with... so, why aren't available is all language? I understand that it is difficult to change JavaScript, yet, when you create a whole new framework, say, nodejs, why not providing coroutines? Does it need a language construct to be efficient? Maybe, then have a look the Icon programming language, where coroutines rule,

sharkbot 16y ago
Lua's primary multitasking primitive is coroutines, and they work quite well. Preemptive threading support can be bolted onto the language, but the coroutine support is well thought-out and elegant, and doesn't suffer from the limitations of Python's generators (i.e., yielding from within nested function calls).
- epall 16y ago
  Monocle (http://saucelabs.github.com/monocle/ http://saucelabs.github.com/monocle/) solves a lot of the issues with using Python generators as coroutines.
silentbicycle 16y ago
Languages that implement efficient coroutines (e.g. Scheme, Lua) usually manage the C stack themselves (like "Stackless" Python). First-class coroutines are very similar to first-class continuations, and many of the same fundamental issues manifest. Lua has one of the best coroutine implementations I've seen. Scheme has continuations which are convertible to coroutines, while Lua has coroutines which are convertible to (one-shot) continuations, with community insight on their use.
- seiji 16y ago
  Silent explained it all very succinctly. If you get confused about coroutines versus continuations versus generators, check out everybody's favorite coroutine manual: http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf
strlen 16y ago
Personally, I view node.JS as a step backwards: it's great to provide the idea of a single thread holding multiple connections, with high-performance non-blocking I/O within each thread; problem is, in their case, there's also a single thread per UNIX process with no primitives for communications between processes (unlike e.g., Erlang/OTP): if you'd want good performance, you want an event loop per logical core.; completely independent processes may be acceptable for simple, stateless web apps, but with most anything else you risk losing a great deal of efficiency without correct primitives. For example, if you have on-disk state, unless the threads are able to share memory (either by running within the same process or using UNIX shm) you're risking a situation where threads are competing for resources like OS page cache (provided you're not doing your own in-process caching and direct I/O, but even in this case, you've now lost the ability share a resource between any two connections without copying). Some e.g., Asana have added fibers to Javascript (in their case V8): http://asana.com/blog/?p=49 http://asana.com/blog/?p=49 The previous post from RethinkDB is quite interesting in terms of motivation for coroutines: to me, this superficially seems like SEDA. Here, instead of stages in the pipeline (thread pool per stage, first stage being processing events from epoll/kqueue, thread per core in each pool, each thread holding state machines, communication between threads via a queue) you are using coroutines for clearer code.
- ericflo 16y ago
  I'm getting an "Error establishing a database connection" on that post. Kind of ironic. I agree about your point regarding IPC, but that's something they can always add later. It's unfortunate that they've gone the callback route instead of innovating like Asana has done with coroutines.
  - strlen 16y ago
    > I agree about your point regarding IPC, but that's something they can always add later. Add some form of IPC as an afterthought? Sure. Create powerful primitives for IPC as done in Erlang/OTP? No.
    - ericflo 16y ago
bkudria 16y ago
"Adding fibers to v8: efficiency + clarity in SSJS": http://asana.com/blog/?p=49 http://asana.com/blog/?p=49

sharkbot 16y ago

Lua's primary multitasking primitive is coroutines, and they work quite well. Preemptive threading support can be bolted onto the language, but the coroutine support is well thought-out and elegant, and doesn't suffer from the limitations of Python's generators (i.e., yielding from within nested function calls).

epall 16y ago
Monocle (http://saucelabs.github.com/monocle/ http://saucelabs.github.com/monocle/) solves a lot of the issues with using Python generators as coroutines.

silentbicycle 16y ago

Languages that implement efficient coroutines (e.g. Scheme, Lua) usually manage the C stack themselves (like "Stackless" Python). First-class coroutines are very similar to first-class continuations, and many of the same fundamental issues manifest. Lua has one of the best coroutine implementations I've seen. Scheme has continuations which are convertible to coroutines, while Lua has coroutines which are convertible to (one-shot) continuations, with community insight on their use.

seiji 16y ago
Silent explained it all very succinctly. If you get confused about coroutines versus continuations versus generators, check out everybody's favorite coroutine manual: http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf

strlen 16y ago

Personally, I view node.JS as a step backwards: it's great to provide the idea of a single thread holding multiple connections, with high-performance non-blocking I/O within each thread; problem is, in their case, there's also a single thread per UNIX process with no primitives for communications between processes (unlike e.g., Erlang/OTP): if you'd want good performance, you want an event loop per logical core.; completely independent processes may be acceptable for simple, stateless web apps, but with most anything else you risk losing a great deal of efficiency without correct primitives. For example, if you have on-disk state, unless the threads are able to share memory (either by running within the same process or using UNIX shm) you're risking a situation where threads are competing for resources like OS page cache (provided you're not doing your own in-process caching and direct I/O, but even in this case, you've now lost the ability share a resource between any two connections without copying). Some e.g., Asana have added fibers to Javascript (in their case V8): http://asana.com/blog/?p=49 http://asana.com/blog/?p=49 The previous post from RethinkDB is quite interesting in terms of motivation for coroutines: to me, this superficially seems like SEDA. Here, instead of stages in the pipeline (thread pool per stage, first stage being processing events from epoll/kqueue, thread per core in each pool, each thread holding state machines, communication between threads via a queue) you are using coroutines for clearer code.

ericflo 16y ago
I'm getting an "Error establishing a database connection" on that post. Kind of ironic. I agree about your point regarding IPC, but that's something they can always add later. It's unfortunate that they've gone the callback route instead of innovating like Asana has done with coroutines.
- strlen 16y ago
  > I agree about your point regarding IPC, but that's something they can always add later. Add some form of IPC as an afterthought? Sure. Create powerful primitives for IPC as done in Erlang/OTP? No.
  - ericflo 16y ago

bkudria 16y ago

"Adding fibers to v8: efficiency + clarity in SSJS": http://asana.com/blog/?p=49 http://asana.com/blog/?p=49