[zxcvcxz]

Here's what I don't understand: If IOCP gives us such a great performance boost why don't I see people using it, even on Windows systems? The first thing that comes to mind is that IOCP can likely only maintain high performance under certain edge-cases that aren't pertinent to the real world, second is that the other I/O models are needed not for unix, but for other aspects of the language its self where IOCP is not appropriate. So IOCP likely causes overhead. I don't know much about it so maybe someone can explain. It sounds revolutionary if it can be applied to the real world and not just edge cases.

[Koromix]

People are used to the POSIX readiness model, that's all. And you can kind of make it work on Windows, even though the performance is not great. OTOH, porting an IOCP-oriented application to Linux will give you catastrophic performance because you need to use many threads to replicate the async model on top of the synchronous Linux I/O calls.

And for some reason, people get very defensive when you point out some of the advantages the NT kernel has over Linux. I mean, I use Linux, I don't like to use Windows but I have no problem admitting the IOCP model is better and async I/O on Linux is a sad broken mess. Denying it only serves to keep it that way.

[politician]

IOCP is the top item on my (short) list of things Windows simply does better. The performance boost you see from designing a server for IOCP from the ground up is jaw-dropping. However, it's hard to grok because it's a very different model, most servers are proprietary code, and the MSDN documentation is barely sufficient (at least, back when I was writing IOCP-based servers in '09).

[trentnelson]

Yeah, I had to figure out how to leverage all the new threadpool stuff with async sockets from scratch for PyParallel, none of the MSDN docs detailed how AcceptEx() and ConnectEx() and DisconnectEx() and all that jazz were meant to be used with CreateThreadpoolIo(), StartThreadpoolIo() etc.

Even bought a couple of Microsoft books and they only covered it at the file I/O level, too. And the last Winsock book is reaaaaaally getting old.

Also, registered I/O is a similar jump in jaw-dropping performance. Disable completion notifications, pre-register all of your buffers on large pages, and use timers to schedule bulk de-queuing of all available completion events.

You definitely need a feedback loop in there to fine-tune the timings, but holy hell does it fly. You basically get a guaranteed-max-latency state machine (given bandwidth, computational cost of request processing, and number of clients connected).

[bitwize]

Inertia and the fact that select/epoll/kqueue loops are "good enough".

[trentnelson]

Bingo.

Not only that but exploiting NT optimally takes a lot of knowledge about a lot of very low-level kernel details, which you sort of need to make a concerted effort to really learn, which is made harder by no official access to (recent) source code.

So I genuinely think there are just fewer programmers out there that specialize in this sort of stuff. There's definitely a correlation between well-above-the-average programmers trending toward open source contribution, but not really the same level of intellectual curiosity about NT/Windows.

One thing I've noticed is that all the people that grok really low level NT kernel details usually end up as reverse engineering experts.

Oh, except for the OSR internals list, that is usually overflowing with clue (both now and historically).

[pjmlp]

It also requires enjoying programming on Windows and buying all the Microsoft Press books that have tons of healthy information how the whole stack works.

Which doesn't work in the free (as in beer) culture world of modern UNIX.

So only those of us that feel like rewarding the work of others do get the information how everything works.

[clevernickname]

The simplest explanation is that the performance benefit of using Windows and implementing just about any Windows-specific design is outweighed by the cost of the Windows licensing fees, when compared to a measurably worse-performing Linux or FreeBSD solution that costs nothing. So very few bother to treat Windows versions of "backend" software as anything but an afterthought.

[dhoe]

It's not even the licencing fees in my opinion. It's that it has had the equivalent of 200 Potterings run amok in it for 30 years. There are so many things that will eclipse any advantage from IO completion ports.

[supernovae]

Not really... the license model provides support and creates fairly standard releases by which you can more easily leverage. If licensing or selling software is your thing. If all you need is something good enough and cheap then licensing could get in the way