Excitement about AIO has been steadily building recently, and a number of contributors have been talking about it and asking me questions about it. I personally have been blocking on the io_cleanups branch which I've been working on with Infinoid. However both he and I have been pretty busy lately with work and life, and haven't been able to lock that branch down as I would have liked.
The io_cleanups branch is a little bit poorly named. I had originally intended it to be a short, fast, cleanup branch to get a few things in line before AIO. But, we took the opportunity to try and add in a proper implementation of pipes too. I would rather have all the pieces present (Files, Pipes, Sockets) when we start AIO so I can remember to make things general enough, then have fewer things implemented but the whole subsystem is a little more clean.
Astute observers will notice that we've already had pipes, in a fashion. Previously we've been able to open pipes to child processes using the FileHandle PMC. However, this mechanism was never very good and was only unidirectional. So Infinoid went through and created a proper bi-directional pipes implementation, which we're working on and testing right now.
The last problem that we're wrestling with is that this new "proper" implementation is a little bit messy. Parrot's IO system was basically written with only FileHandles in mind, and Pipes are a little bit shoehorned in right now. So ironically the "io_cleanups" branch actually introduced a new feature that is a little messy and didn't actually perform many cleanups. As much as I would like to resolve this little irony, I would far prefer to get a working Pipes implementation merged into trunk now. The branch is already too long-lived as it stands, and I really want to just reach the nearest stable point and merge it into trunk so we can start planning out the next moves.
Japhb was talking about adding D-Bus support to Parrot by wrapping the D-Bus libraries in PIR. Unfortuately, this is going to require better support in Parrot for asynchronous events and asynchronous IO operations. So, this is a good motivator to get AIO working, and is also a good use-case to help drive AIO development.
So as soon as the pipes thing stabilizes in the branch, I want to lock it down and merge it in. Then, I want to get started on AIO shortly thereafter. There is enough interest and even demand building at this point that I don't want to delay any more then necessary.