3 ms·

You're correct, it would not be impossible to write coroutine safe code in node.js. The problem is just that coroutines are not natural in JS, and people will

You're correct, it would not be impossible to write coroutine safe code in node.js. The problem is just that coroutines are not natural in JS, and people will shoot themselves in the foot all the time. Some "features" are better left out to allow a bigger audience to write reliable Software. Your milage may vary.

jules 16y ago
Perhaps, but in my experience using coroutines is easier than using callbacks because coroutines make code look the same as if it was synchronous. readAsync(function(x) { readAsync(function(y) { write(x+y) }) }) vs x = read() y = read() write(x+y) You don't really need to know how to use the full power of coroutines if you just want asynchronous operations. You just need to know that read() may block the current coroutine.
- pmjordan 16y ago
  You could even be more explicit about the whole thing, use futures and only allow them to block. The above example would go something like this if the reads can't be executed concurrently: future_x = read(); x = future_x.wait(); y = read().wait(); // shortcut write(x + y); Or something like this if the reads are independent: future_x = read(); future_y = read(); // one of a handful of functions that can "block", all operating on futures: waitForAll(future_x, future_y); write(future_x.get() + future_y.get()); Using futures rather than implicit suspension has the added advantage of being able to pipeline independent reads just as you can with callback-style asynchronous I/O. You can already implement[1] an approximation of this in terms of callbacks, but it doesn't look quite as nice, e.g.: var handler = new AsyncHandler(); // independent, pipelined reads readAsync(handler.cb()); readAsync(handler.cb()); handler.whenDone(function(x, y) { write(x+y); }); It gets substantially uglier than that if the dependencies aren't so straightforward, e.g. A, B & C are independent, D depends on A & B having completed and the last part of the code requires the results from C & D. Futures do much better in that sort of situation. [1] I've built a basic but usable helper for this purpose: http://github.com/pmj/MultiAsync-js/tree/master/src/ http://github.com/pmj/MultiAsync-js/tree/master/src/ I hear the Dojo toolkit contains something similar.
  - jules 16y ago
    Excellent :) Why do you have a separate wait & waitForAll? Couldn't get() wait automatically?
    - pmjordan 16y ago
      I was just throwing ideas out there, not really thinking it through. :) Although you're absolutely right about waitForAll() in that example, there is a point to that sort of function, say if you wanted to add a timeout. Or you could have a waitForAny() function - useful if you only need one of the futures to finish before proceeding. get() vs. wait() is admittedly a question of preference. Personally, I'd keep them separate and even go so far as to have it warn you if you called get() without a wait() or a successful isReady() or so on that future. It keeps the suspensions explicit and the intentions clear. It's a bit like explicit vs implicit transactional systems.
      - bruceboughton 16y ago
        Out of interest, is this any different to WaitHandles + async delegates in .NET? Doesn't look like it to me but I could be missing something: Func<string> reader = read; IAsyncResult future_x = reader.BeginInvoke(null, null) IAsyncResult future_y = reader.BeginInvoke(null, null) WaitHandle.WaitAll(new[] { future_x.AsyncWaitHandle, future_y.AsyncWaitHandle }); // takes optional timeout string x = reader.EndInvoke(future_x); string y = reader.EndInvoke(future_y); write(x + y);
        pmjordan 16y ago
        Looks like it's essentially the same type of programming model, although I have a feeling WaitHandle.WaitAll() just blocks the current thread. In the ideal case, it would internally call the event loop coroutine and process other events instead without sending the thread to sleep. Thread scheduling involves system (kernel) calls, coroutines are purely userspace, just like node.js's async callback mechanism.

jules 16y ago

Perhaps, but in my experience using coroutines is easier than using callbacks because coroutines make code look the same as if it was synchronous. readAsync(function(x) { readAsync(function(y) { write(x+y) }) }) vs x = read() y = read() write(x+y) You don't really need to know how to use the full power of coroutines if you just want asynchronous operations. You just need to know that read() may block the current coroutine.

pmjordan 16y ago
You could even be more explicit about the whole thing, use futures and only allow them to block. The above example would go something like this if the reads can't be executed concurrently: future_x = read(); x = future_x.wait(); y = read().wait(); // shortcut write(x + y); Or something like this if the reads are independent: future_x = read(); future_y = read(); // one of a handful of functions that can "block", all operating on futures: waitForAll(future_x, future_y); write(future_x.get() + future_y.get()); Using futures rather than implicit suspension has the added advantage of being able to pipeline independent reads just as you can with callback-style asynchronous I/O. You can already implement[1] an approximation of this in terms of callbacks, but it doesn't look quite as nice, e.g.: var handler = new AsyncHandler(); // independent, pipelined reads readAsync(handler.cb()); readAsync(handler.cb()); handler.whenDone(function(x, y) { write(x+y); }); It gets substantially uglier than that if the dependencies aren't so straightforward, e.g. A, B & C are independent, D depends on A & B having completed and the last part of the code requires the results from C & D. Futures do much better in that sort of situation. [1] I've built a basic but usable helper for this purpose: http://github.com/pmj/MultiAsync-js/tree/master/src/ http://github.com/pmj/MultiAsync-js/tree/master/src/ I hear the Dojo toolkit contains something similar.
- jules 16y ago
  Excellent :) Why do you have a separate wait & waitForAll? Couldn't get() wait automatically?
  - pmjordan 16y ago
    I was just throwing ideas out there, not really thinking it through. :) Although you're absolutely right about waitForAll() in that example, there is a point to that sort of function, say if you wanted to add a timeout. Or you could have a waitForAny() function - useful if you only need one of the futures to finish before proceeding. get() vs. wait() is admittedly a question of preference. Personally, I'd keep them separate and even go so far as to have it warn you if you called get() without a wait() or a successful isReady() or so on that future. It keeps the suspensions explicit and the intentions clear. It's a bit like explicit vs implicit transactional systems.
    - bruceboughton 16y ago
      Out of interest, is this any different to WaitHandles + async delegates in .NET? Doesn't look like it to me but I could be missing something: Func<string> reader = read; IAsyncResult future_x = reader.BeginInvoke(null, null) IAsyncResult future_y = reader.BeginInvoke(null, null) WaitHandle.WaitAll(new[] { future_x.AsyncWaitHandle, future_y.AsyncWaitHandle }); // takes optional timeout string x = reader.EndInvoke(future_x); string y = reader.EndInvoke(future_y); write(x + y);
      - pmjordan 16y ago
        Looks like it's essentially the same type of programming model, although I have a feeling WaitHandle.WaitAll() just blocks the current thread. In the ideal case, it would internally call the event loop coroutine and process other events instead without sending the thread to sleep. Thread scheduling involves system (kernel) calls, coroutines are purely userspace, just like node.js's async callback mechanism.