4 ms·

Task.js: Beautiful Concurrency for JavaScript

77 points by DanielRibeiro 14y ago

deleted 14y ago
[deleted]
derefr 14y ago
Huh; I wonder if a slight tweak to this could be used to make yield act like Erlang's receive operator? Presuming the library assigns every task a handle (a PID), that tasks could .send() messages to other tasks, etc., .receive() could be implemented by the library just expecting you to yield a set of patterns, then blocking your task until the library has a message to route to it that matches one of those patterns.
- kevingadd 14y ago
  I think in practice you could just do this with encapsulation - i.e. you'd create channel objects and yield on them, instead of assigning handles directly to tasks.
- fzzzy 14y ago
  Yep. I wrote some code a few years ago that does this. I wrote it before I knew about task.js and should rewrite it using task.js, removing my handrolled clone of it. https://github.com/fzzzy/pavel.js https://github.com/fzzzy/pavel.js There is also another slightly different scheduler that I started that includes a multithreaded scheduler with webworkers and works in a browser. This version, because it is designed to work in stock browsers, has a callback api and does not use generators, but task.js could easily be layered on top. https://github.com/fzzzy/actors.js https://github.com/fzzzy/actors.js Please excuse the use of an explicitly provided "pattern" string in both of these. I did it for simplicity. It would be possible to port my concept of shapes from my python-actors project to js, but the runtime overhead of using explicit strings is extremely low and it makes the code very simple.
deleted 14y ago
[deleted]
pyalot2 14y ago
In python we've been having a yield statement for a long time. By far and large, it has not solved the issue of cooperative multitasking. Using it only leads to near incomprehensive code where everything becomes an iterable, and every call becomes an iteration. Co-routines solve cooperative multitasking. Which is why they're now being discussed for python in a fashion that doesn't rely on C-stack hacks.
- kevingadd 14y ago
  A better way to think of this is in terms of degrees of improvement. Going from pure callback passing to yield-based cooperative multitasking increases clarity and removes a lot of opportunities for mistakes, so in practice it ends up being a win - but just like callback passing, you can still hit a point where it's too complicated or you're having to do too much. It's only natural that going from custom task schedulers built on 'yield' to language-native mechanisms for cooperative multitasking improves things further. Even that, though, will likely not 'solve the issue', just make it considerably easier to tackle for individual applications. There's no One True Scheduler or One True Task Primitive, at least as far as I know: everyone seems to want something slightly different.
- lucian1900 14y ago
  I would say it has almost entirely solved the problem. Twisted with inlineCallbacks makes writing multitasking programs very clear and obvious. Python 3.3 makes it even better by allowing `return` and requiring less wrapping with `yield from`. Implicit stack coroutines (like greenlets) can always be built on top if necessary, but they tend to require horrible things like monkey patching to work together with existing synchronous, blocking code.
  - denik 14y ago
    > Implicit stack coroutines (like greenlets) can always be built on top if necessary, but they tend to require horrible things like monkey patching to work together with existing synchronous, blocking code. that's not true. monkey patching is an optional feature that you can use with greenlet-based libraries, but you don't have to. compare that to inlineCallbacks, where you don't have that option.
mrspeaker 14y ago
I wish Chrome would start implementing some of the ES6 stuff (especially arrow function syntax...mmmm): does anyone know where we can see that kinda status?
- just2n 14y ago
  Check the Chromium blog and their bug tracker. If this were implemented, it would be hidden behind the experimental JS flag anyway.
  - deleted 14y ago
    [deleted]
- fzzzy 14y ago
  You can see some es6 features that are already in v8 and accessible from node here: http://stackoverflow.com/questions/13351965/what-does-node-harmony-do http://stackoverflow.com/questions/13351965/what-does-node-h... No generators yet but they are currently being worked on.
ger_phpmagazin 14y ago
This is a year old. Now what?

77 points by DanielRibeiro 14y ago

deleted 14y ago

[deleted]

Huh; I wonder if a slight tweak to this could be used to make yield act like Erlang's receive operator? Presuming the library assigns every task a handle (a PID), that tasks could .send() messages to other tasks, etc., .receive() could be implemented by the library just expecting you to yield a set of patterns, then blocking your task until the library has a message to route to it that matches one of those patterns.

kevingadd 14y ago
I think in practice you could just do this with encapsulation - i.e. you'd create channel objects and yield on them, instead of assigning handles directly to tasks.
fzzzy 14y ago
Yep. I wrote some code a few years ago that does this. I wrote it before I knew about task.js and should rewrite it using task.js, removing my handrolled clone of it. https://github.com/fzzzy/pavel.js https://github.com/fzzzy/pavel.js There is also another slightly different scheduler that I started that includes a multithreaded scheduler with webworkers and works in a browser. This version, because it is designed to work in stock browsers, has a callback api and does not use generators, but task.js could easily be layered on top. https://github.com/fzzzy/actors.js https://github.com/fzzzy/actors.js Please excuse the use of an explicitly provided "pattern" string in both of these. I did it for simplicity. It would be possible to port my concept of shapes from my python-actors project to js, but the runtime overhead of using explicit strings is extremely low and it makes the code very simple.

deleted 14y ago

[deleted]

pyalot2 14y ago

In python we've been having a yield statement for a long time. By far and large, it has not solved the issue of cooperative multitasking. Using it only leads to near incomprehensive code where everything becomes an iterable, and every call becomes an iteration. Co-routines solve cooperative multitasking. Which is why they're now being discussed for python in a fashion that doesn't rely on C-stack hacks.

kevingadd 14y ago
A better way to think of this is in terms of degrees of improvement. Going from pure callback passing to yield-based cooperative multitasking increases clarity and removes a lot of opportunities for mistakes, so in practice it ends up being a win - but just like callback passing, you can still hit a point where it's too complicated or you're having to do too much. It's only natural that going from custom task schedulers built on 'yield' to language-native mechanisms for cooperative multitasking improves things further. Even that, though, will likely not 'solve the issue', just make it considerably easier to tackle for individual applications. There's no One True Scheduler or One True Task Primitive, at least as far as I know: everyone seems to want something slightly different.
lucian1900 14y ago
I would say it has almost entirely solved the problem. Twisted with inlineCallbacks makes writing multitasking programs very clear and obvious. Python 3.3 makes it even better by allowing `return` and requiring less wrapping with `yield from`. Implicit stack coroutines (like greenlets) can always be built on top if necessary, but they tend to require horrible things like monkey patching to work together with existing synchronous, blocking code.
- denik 14y ago
  > Implicit stack coroutines (like greenlets) can always be built on top if necessary, but they tend to require horrible things like monkey patching to work together with existing synchronous, blocking code. that's not true. monkey patching is an optional feature that you can use with greenlet-based libraries, but you don't have to. compare that to inlineCallbacks, where you don't have that option.

mrspeaker 14y ago

I wish Chrome would start implementing some of the ES6 stuff (especially arrow function syntax...mmmm): does anyone know where we can see that kinda status?

just2n 14y ago
Check the Chromium blog and their bug tracker. If this were implemented, it would be hidden behind the experimental JS flag anyway.
- deleted 14y ago
  [deleted]
fzzzy 14y ago
You can see some es6 features that are already in v8 and accessible from node here: http://stackoverflow.com/questions/13351965/what-does-node-harmony-do http://stackoverflow.com/questions/13351965/what-does-node-h... No generators yet but they are currently being worked on.

ger_phpmagazin 14y ago

This is a year old. Now what?