Hacker News Reader

Comment by jules | Hacker News Reader

That is not a good argument either. If you are going to write your entire IO library in asynchronous style like node.js then you could easily make all IO routines coroutine safe. In fact you have exactly the same problem whether you use coroutines or not. If you have a nice asynchronous program and I call wait in the middle that's going to hurt you in the same way.

View on HN

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.

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)
      })
    })

    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.

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/ I hear the Dojo toolkit contains something similar.

Excellent :)

Why do you have a separate wait & waitForAll? Couldn't get() wait automatically?

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.

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);

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.

Reply on news.ycombinator.com