Как оказывается, еще более поразительным является то, что даже те, кто вроде бы и знают о существовании асинхронного ввода/вывода, совершенно не представляют себе что это такое и почему это единственный правильный способ.

ну начнём с того что это апи для работы с фс, а не сетью.

Ну начнем с того, что подтвердить это утверждение очень просто — нужно всего лишь привести цитатку из стандарта. Предупреждая Вашу попытку выставить aio_fildes как доказательство, отмечу, что socket возвращает как раз его: «Upon successful completion, socket() shall return a non-negative integer, the socket file descriptor».

Более того, в Линуксе есть асинхронные операции предназначенные исключительно для работы с диском, пусть это и является довольно уродливым решением с точки зрения дизайна.

а закончим тем что в случае с проактор паттерном приходится выделять буфферы для чтения на каждый сокет чтобы пропихнуть его в aio_read

Вот Вы сейчас противопоставляете необходимость выделения буфера под прием данных чему? Неужели сокет сам по себе не имеет буфера на прием? Неужто SO_RCVBUF в Линуксе по умолчанию установлен в 0 и любые данные, на которые нет outstanding read мгновенно теряются. Вот это новость.

Но позвольте мне продолжить Вашу мысль:

В-третьих: мы избавляемся от лишнего копирования: сначала в буфер драйвера tcp, а потом в пользовательский (пользователь в данном случае — это пользователь API, то есть программист). К тому же при наличии TOE (да, я знаю, что он не решает «проблему» c10k, но он очень хорошо вписывается в модель асинхронного ввода/вывода) количество копирований можно сократить до 0 (НУЛЯ): с «провода» сразу в пользовательский буфер по DMA.

В-четвертых: мы снижаем задержки (latency) и снижаем нагрузку на процессор. С неблокирующим вводом/выводом нам нужно как минимум два раундтрипа в ядро и обратно: сначала с нотификацией, что есть данные, а потом поход за самими данными. В то же время асинхронный ввод/вывод разбудит нас сразу с данными.

В-пятых: асинхронный ввод/вывод концептуально чище: он превращается в синхронный (блокирующий или нет) всего лишь оберткой с одним дополнительным wait-ом в конце, в то время как синхронный в асинхронный не превращается никак (можно придумать схемы с пулом потоков или с порождением новых потоков на каждую операцию, но они будут либо слишком «дорогими», либо слишком неустойчивыми к «нестандартной» нагрузке, либо и то другое вместе).

Список можно продлжать, но на мой взгляд, то что приведено выше — уже достаточно веские основания задуматься.

В заключение хочу отметить, что конкретная РЕАЛИЗАЦИЯ асинхронного ввода/вывода может быть очень плохой (что в случае Линукса меня бы совершенно не удивило), что не отменяет моего изначального тезиса о том, что настоящий асинхронный ввод/вывод имеет кучу преимуществ перед «неблокирующим», в то время как обратное несправедливо: нет ни одного преимущества «неблокирующего» ввода/вывода перед асинхронным.