Здравствуйте, alex_public, Вы писали:

S>>Подождите, автор говорил про iocp потоки пула, как результат работы io на самом верху (механизм передачи результата).

_>И? Какая разница, если в наше приложение данные придут не через фиксированное время после попадания их в оперативную память, а через некоторое неопределённое, когда там освободятся все нужные очереди, планировщики и т.п.? В этом смысле даже обычный синхронный api будет эффективнее.

А какое будет отличие, если железо все равно асинхронное? За исключением того, что у системы будет отъеден и будет простаивать поток,
разницы, кмк, нету.

_>Вообще в этой области есть три классических подхода:

_>1. блокировка (до выполнения задачи)
_>2. опрос (о статусе выполнения задачи)
_>3. асинхронный вызов (коллбэк)

_>Так вот асинхронный ввод-вывод в винде иногда по незнанию позиционируют как третий вариант, но на самом деле там чисто второй, только слегка закумуфлированный. В линухе тоже самое (epoll), но они хотя бы честно говорят об этом, а не пытаются создать видимость настоящей асинхронности.

Я правильно понимаю, что идет опрос (2) всех зарегестрированных io операций, после чего у готовых дергаетс callback (скорее всего это так)?

А как можно асинхронный вызов осуществить "по-настоящему", а не через опрос+callback? По идее, должно быть эффективнее,
ибо не надо делать O(N) проверок io готовности. Т.е. сам io объект должен дернуть callback, так? Ну тогда венда и делает (3) вариант...

S>>А кто сказал, что эти потоки ждут? Сам факт нахождения их в пуле говорит об обратном -- это всего лишь способ
S>>диспетчеризации результата io в приложение. Т.е. iocp поток это не самый обычный поток, скажем так.

_>Ты похоже невнимательно прочитал документацию по IOCP. )

Не уверен, что ссылка которую дали, но вот:

The most efficient scenario occurs when there are completion packets waiting in the queue, but no waits can be satisfied because the port has reached its concurrency limit. Consider what happens with a concurrency value of one and multiple threads waiting in the GetQueuedCompletionStatus function call. In this case, if the queue always has completion packets waiting, when the running thread calls GetQueuedCompletionStatus, it will not block execution because, as mentioned earlier, the thread queue is LIFO. Instead, this thread will immediately pick up the next queued completion packet. No thread context switches will occur, because the running thread is continually picking up completion packets and the other threads are unable to run.

https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports

Где тут блокировка?