Squawks of the Parrot

WCB: Async IO

Parrot was supposed to have a fully layered, asynchronous IO system, with completion callbacks and layers, something akin to a cross between the SysV (or Tcl) streams system and VMS's asynchronous IO system.

That is, when your program posts a read or write to a filehandle what happens is that the IO request is put into the file handle's queue

Why build in an async IO system from the beginning? Heck, why do async IO in the first place?

The reason to do async IO is simple. Performance. You'll get significantly better throughput with a properly written async IO capable program than you will with one that does synchronous IO. ("significantly better" here being a factor of three or four in some cases. Depends on the hardware to some extent) The nice thing is that, unless you've got a horrifically CPU-intensive program, you'll get a performance win. (More detail's really a subject of a what the heck post, so I'll stop here)

There are two reasons to build one into parrot in the first place. The first is that while it's pretty straightforward to build a synchronous IO system ontop of an async one, it's a big pain to build an async one on top of a synchronous system. (And yes, given how ubiquitous async IO systems aren't, I know that parrot would've had to do this on some platforms)

The second reason's a practical one -- if one wasn't built we stood a good chance of people building three or four (or five, or six, or...) async systems, all of which were incompatible. You can see this in perl now (and in other languages I expect) with event loops -- every GUI's got one, there are usually a few different generic event loops, and an async IO system or two thrown into the mix. It's all messy. (Async IO and event loops don't have to go together, but they can, and usually do, even if it's not obvious in the programming interface that's exposed) Having one standard system would've meant that anyone who needed some sort of asynchronous system (for IO, events, or whatever) could just tie into the standard one, rather than write their own. Easier for the people writing the interface, since there's less code to write, and easier for people using it, since things would mix and match better.

The basic IO system was going to be a standard completion callback with marker system. That is, you could attach a sub to each IO request, and the system would call the sub when the IO request was complete. Each async IO request would also have a marker you'd get back that you could use to figure out what state the request was in -- was it pending, or complete, or in the process of having its completion routine run, or whatever. It was going to tie into the event system under the hood, but that's a post for another day.

Pity, that. Would've been cool, and could've made for some screaming throughput. Ah, well, such is life.