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

vf>>Для send все не так очевидно, своя очередь — получается дублирует механизм предаставляемый стеком, что не есть правильно ИМХО.

D>Вы не правы. На сервере есть такие функции, которые хотят клиенту кинуть срочные данные. И если при этом буфер исходящих сообщений полон, то эти функции совсем "не хотят" ожидать пока там данные уйдут в сеть (пока от очередного вызова WSASend сработает GetQueuedCompletionStatus).

Не прав в чем? Я согласен, что для верхнего уровня должно быть все прозрачно. Вопрос в реализации, я не считаю что нужно все запросы на передачу прогонять через свою очередь, потому что:
1. Не нужно на себя брать функции системы пока это не нужно
2. Для серверов поведение приводящее к переполнению исход. очереди не типично (запрос-ответ), и IOCP этому не способстует — разумно ограничивая число потоков

Аргумент Jolly Roger мне понятен, я согласен что так проще, но см. выше.

Опять же, все это только про send, про receive я убежден что должно быть несколько запросов в очереди.

D>Эти функции просто в крит. секции должны копировать данные в спец. буфер отправки и работать дальше. А уж отдельный поток пусть сам дожидаться уведомления о выполнении WSASend и вызывает следующий WSASend.

Копировать?! Думаю, про копирование вообще речи не идет...

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

JR>>Тоже нет. Но вот с одновременным вызовом нескольких WsaSend или WsaRecv не столь однозначно, и дело даже не в потокобезопасности самих функций, с этим в асинхронном режиме всё в порядке. Трудности в логике обработки уведомлений о завершении. Например, если у Вас будет несколько активных запросов на чтение из одного сокета, то может статься, что уведомление о получении разных частей одного пакета Вы получите в разных потоках, и сборка такого пакета в единое целое может оказаться делом нетривиальным. И зачем оно?

vf>Затем чтобы исключить копирования из внутренних буферов стэка при Recv, ведь если операции чтения нет в очереди — этого не избежать. Это одна из ключевых фич IOCP.

Как множественные WsaRecv помогут уменьшить количество копирований?

Попробуйте задать нулевой размер приёмного буфера, для расширения кругозора. Множественные WsaRecv всего лишь добавят во многих случаях необходимость копировать данные из их буферов при сборке пакета. Не говоря уж о том, что совершенно не понятно, как потом из этих буферов собирать единый пакет, как определять порядок их следования. И всё это вместо того, чтобы передать достаточный буфер (или список буферов) в одном вызове WsaRecv.

vf>Для send все не так очевидно, своя очередь — получается дублирует механизм предаставляемый стеком, что не есть правильно ИМХО.

Ну так Вы попробуйте практически, и станет очевидно
Это неправильное ИМХО. В описанной ТС схеме создания своей очереди не избежать, и я уже писал, почему.

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

vf>>Затем чтобы исключить копирования из внутренних буферов стэка при Recv, ведь если операции чтения нет в очереди — этого не избежать. Это одна из ключевых фич IOCP.

JR>Как множественные WsaRecv помогут уменьшить количество копирований?

Если в очереди есть запрос, стэк будет писать сразу в буфер, если его нет — очевидно где-то во внутренние буфера, из которых потом будет копировать.

JR>Попробуйте задать нулевой размер приёмного буфера, для расширения кругозора. Множественные WsaRecv всего лишь добавят во многих случаях необходимость копировать данные из их буферов при сборке пакета.

Да, такая необходимость может возникнуть. Но 1. реальности возникает крайне редко 2. если проанализировать варианты (учитывая что стеку тоже придется копировать в отсуствие запроса), то видно что тот кто владеет полной информацией о пакете может делать меньше копирований. Ну может быть за исключением случая когда заранее известен размер пакета.
Так же возможны варианты когда пакет можно разобрать не склейвая, или его вообще нет необходимости разбирать, а нужно просто переслать.

JR>Не говоря уж о том, что совершенно не понятно, как потом из этих буферов собирать единый пакет, как определять порядок их следования.

Мне понятно, если будет интересно могу рассказать свое решение.

JR>И всё это вместо того, чтобы передать достаточный буфер (или список буферов) в одном вызове WsaRecv.

Достаточный для чего? Если размер пакета не известен: 1. размер пакета идет в заголовке, 2. пакет в текстовом виде и его нужно распарсить чтобы определить конец?

vf>>Для send все не так очевидно, своя очередь — получается дублирует механизм предаставляемый стеком, что не есть правильно ИМХО.
JR>Это неправильное ИМХО. В описанной ТС схеме создания своей очереди не избежать, и я уже писал, почему.

Я соб-но тоже свои аргументы привел, остаюсь при своем мнении.