Hacker News Reader

Comment by viraptor | Hacker News Reader

There's one thing that bugs me in this document (well, a couple more, but this is the biggest) - page 64:

> Multithreaded server coding is more intuitive - You simply follow the flow of whats going to happen to one client

Is it really? I'd agree if we were talking about something like server spawning a scripting language probably, but in other cases? Most network endpoints are described as state machines. They're not supposed to "flow" - they're responding to input and changing their state. I'd claim that if you implement a protocol with more than 5 states as a properly abstracted state machine, it would be more intuitive than anything that's supposed to emulate "flow". And that's more natural in asynchronous design.

View on HN

Note that the difference vanishes when the language allows for closures. With closures, you can write code that looks like "one thread per request", but could in fact be using asynchronous I/O:

  wait_for_response(request, function(response) {
      do_something_with_response(response)
      ...
  })

This becomes even more clear in Ruby syntax, where you don't have to nest the reply handler into the wait_xxx function:

  wait_for_response(request) { |response|
      do_something_with_response(response)
      ...
  }

Using monads, you can even abstract the difference away completely. That way, the code looks like ordinary imperative stuff:

  response <- wait_for_response(request);
  do_something_with_response(response)

If your language provides continuations, you can even handle multiple responses that way. Paul Graham did that in Viaweb (http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt, section "Closures Simulate Subroutines").

tl;dr: The asynchronous I/O is only hard to use in languages which lack essential features. In modern languages you can write "intuitive" code that works for both cases, and you are free to switch from multithreaded sync I/O to asynchronous I/O as you like.

I think it depends on what you are doing. If the app has a single logical thread of execution, then sequential code is easier to understand than a series of callbacks. If the app executes steps in parallel with forks and joins, then a state machine implemented with callbacks can be easier to understand.

The typical web app falls in to the former category: validate input, read from cache, maybe read from database, maybe write to database, generate response.

If youre passing any state around with the callbacks or have shared global state then having callbacks will not buy you anything over the sequential code with loops, branches and joins imo. I think to prove correctness about the shared state you pretty much have to infer the loops, branches and joins.

It's more intuitive in the sense that you just do:

    while (read(...)) {
       ...
    }

instead of:

    if (read(...) == EWOULDBLOCK) {
        yield();
    } else {
        manage buffer
    }

This can be mitigated pretty well by a good library, EventMachine for example. It handles the evented complexities for you, all you need do is provide an event source and a callback.

Don't forget you need to make sure your callback doesn't itself block, or take too long.

(Which in turn implies that all the other libraries you are using --at least ones that need to communicate-- need to have pretty deep integration with your "good library," or you're going to be writing that integration yourself.)

(Not that threading is immune here... you need to be careful choosing libraries such that they are re-entrant, etc. But threading has held more mindshare for much longer, and most OSes share a roughly similar model, so they have a large head start on this front.)

Real event code never looks like this. You get a callback on read-readiness. You read as much as you can into a buffer. You split the buffer into requests. You act on each request.

Only a tiny bit of your code ever touches send/recv. It never gets EWOULDBLOCK (it's only running because select told it to!). Most of your code deals with entire requests; the state it's saving is largely identical to what a sychronous server deals with; the overhead is in having to hot-potato it through multiple functions.

Reply on news.ycombinator.com