That's not really a fair comparison: Windows I/O completion ports are a proprietary standard that is part of the NT kernel, while POSIX AIO is just a user-space libc extension that was added later on (as far as I know, none of the kernel-space posix AIO proposals got merged in). It's easier to get things right when you defined your own standards, at the cost of portability.

But even then, you might argue that that completion ports are less than ideal: you incur a lot of complexity in the file system drivers, while e.g. solaris/BSD offer similar functionality without that burden.

I'm not familiar with BeOS at all, but browsing through Haiku's API documentation I can't really find much. What exactly were you referring to?

If you're talking about Linux specifically, that's not quite accurate history. Prior to POSIX threads, Linux had it's own threading model--Linux Threads--which frankly was terrible. They added the full POSIX later on in part b/c the Linux threading was so awful. [1] has more detail.

[1] https://en.wikipedia.org/wiki/LinuxThreads

True that, but I was talking about the POSIX async I/O API: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/aio.... I don't know much about the LinuxThreads-era.

Both LinuxThreads and the current NPTL are implementations of POSIX threads. NPTL is closer to the standard, but if your code doesn't need the stricter conformance, it could run on either with no changes.

Proprietary or not is something quite orthogonal to my comment. I was commenting on the design of the API, its implementation and the leak of the abstractions used etc. etc. Async was never Unix's strength, plan9 might have fixed matters somewhat if it caught on.