I’m glad to see this. I always wonder how much of our software busy-polls deep under the hood rather than take advantage of more efficient, platform-specific mechanisms.

It underscores a few things for me:

• asynchrony is not an easy problem
• edge-triggered IO at least consolidates the damage for some architectures
• IO, threads, and state are an unholy trinity of complexity

Been thinking on this lately as I work on a client project requiring use of middleware that has it’s own ideas about these things.

my CPU doesn’t execute intentions; it executes instructions. (••) / ( ••)>⌐■-■ / (⌐■_■)

My favorite part was:

void
chrome(void)
{
    if (poll() && (poll() || poll()))
        while (poll())
            switch (poll()) {
            case poll():
                poll();
            }
}

I’ve really enjoyed this series from @tedu. I, coincidentally, have been playing with dtrace a bunch lately (and reading the book) to get a system-wide view of a program. It’s interesting to see all of these things come together and all of the hidden things in there. I think what’s missing is a good way to go from seeing these things to drilling down into the code to figure out where it happens. dtrace offers this with the ustack function but the code has to be compiled with symbols for that to make sense.