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

MC>>А где ее еще обрабатывать, если уведомления не будет?

G>Вариант с возвратом ошибки чем плох?

Возвратом куда? И как это должно сменить поток?

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

MC>Возвратом куда?

В вызывающую функцию, куда ж ещё.

DWORD Send(...)
{
    ...
    WSASend(...);
    ...
    return dwRet;
}

MC>И как это должно сменить поток?

Зачем?

Правда я с asio не работал, может там все не так как везде.

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

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

P>>я WSABUF размещаю в куче и тащу адрес через поле OVERLAPPED на завершение — где и освобождаю/переразмещаю , за 9 месяце ни одного слета

MC>Ваши 9 месяцев не отменяют утверждения в MSDN по поводу необходимости держать WSABUF до выхода из WSASend (именно до выхода из WSASend, а не до завершения операции).

ок, спасибо, вот прочитал этот абзац — ведь мы на вход WSASend подаем в общем случае массив структур WSABUF (пара длина / адрес данных), меня (возможно !) спасает от слета тот факт, что этот массив у меня сознательно одноэлементный , а если у кого-то в нем сотни буферов на передачу, то тут высоковероятна шляпа — за одно завершение этот массив не отправится и значит не следует его валить на первом же завершении , т.е. предупреждение авторов документации оно для всех и на все случаи, так что ли

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

MC>>Возвратом куда?
G>В вызывающую функцию, куда ж ещё.

Будет еще один if, теперь уже в вызывающй функции. Толку-то?
А так — обычный обработчик немедленного выполнения операции.
Не забывай, что boost::asio не ограничивается Windows. Если WSASend отправляет уведомление всегда, даже в случае немедленного выполнения, то для методов на других системах (kqueue, epoll, ...) это [может быть] не так.

MC>>И как это должно сменить поток?
G>Зачем?

Ты возмущался, что они-де "предлагают ошибку обрабатывать в рабочем потоке".

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

P>а если у кого-то в нем сотни буферов на передачу, то тут высоковероятна шляпа — за одно завершение этот массив не отправится и значит не следует его валить на первом же завершении

Уведомление о завершении операции одно и только одно на операцию, вне зависимости от количества структур WSABUF.

А спасает тебя скорее всего конкретная реализация [на конкретной версии Windows], которая на самом деле не трогает WSABUF после начала операции. Но нет гарантии, что эта реализация не меняется (или не будет меняться) от версии к версии.

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

MC>Уведомление о завершении операции одно и только одно на операцию, вне зависимости от количества структур WSABUF.

э-э-э-э, стоп, прямой зависимости нет , но так понимаю чем больше данных ставим на передачу (вот тот же массив WSABUF погуще), тем все таки вероятней, что сетевая подсистема будет отсылать их частями и уведомлений о завершении операции будет более одного

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

MC>>Уведомление о завершении операции одно и только одно на операцию, вне зависимости от количества структур WSABUF.

P>э-э-э-э, стоп, прямой зависимости нет , но так понимаю чем больше данных ставим на передачу (вот тот же массив WSABUF погуще), тем все таки вероятней, что сетевая подсистема будет отсылать их частями и уведомлений о завершении операции будет более одного

Еще раз. ОДНО И ТОЛЬКО ОДНО.

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

MC>ОДНО И ТОЛЬКО ОДНО.

Тут даже я чуть в штаны не наделал!!

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

MC>Будет еще один if, теперь уже в вызывающй функции. Толку-то?
MC>А так — обычный обработчик немедленного выполнения операции.

Я к тому, что сложная функция должна вернуть код ошибки, а не выдавать его через хитрый механизм.
А если после Send() надо выполнить код, зависящий от этого?

MC>Ты возмущался, что они-де "предлагают ошибку обрабатывать в рабочем потоке".

Угу. Считаю, это ненормально.

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

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

MC>>>Уведомление о завершении операции одно и только одно на операцию, вне зависимости от количества структур WSABUF.

P>>э-э-э-э, стоп, прямой зависимости нет , но так понимаю чем больше данных ставим на передачу (вот тот же массив WSABUF погуще), тем все таки вероятней, что сетевая подсистема будет отсылать их частями и уведомлений о завершении операции будет более одного

MC>Еще раз. ОДНО И ТОЛЬКО ОДНО.

вот это подозреваю действительно платформозависимое утверждение

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

P>>>э-э-э-э, стоп, прямой зависимости нет , но так понимаю чем больше данных ставим на передачу (вот тот же массив WSABUF погуще), тем все таки вероятней, что сетевая подсистема будет отсылать их частями и уведомлений о завершении операции будет более одного

MC>>Еще раз. ОДНО И ТОЛЬКО ОДНО.

P>вот это подозреваю действительно платформозависимое утверждение

Отнюдь. На этом, собственно, все и работает. Один вызов ввода-вывода — одно и только одно уведомление.

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

MC>Отнюдь. На этом, собственно, все и работает. Один вызов ввода-вывода — одно и только одно уведомление.

кабы так зачем тогда GetQueuedCompletionStatus() второй параметр :

lpNumberOfBytes
[out] Pointer to a variable that receives the number of bytes transferred during an I/O operation that has completed.

если всегда одно срабатывание на один инициатор отсылки/приема ?

можно было бы думать, что на случай когда частичная отсылка — результат отказа на транспорте и нам надо знать что таки ушло (зачем ??) , но таки это нигде не сказано, вот уже где действительно лучше перестраховаться если нет прямых указаний вести себя так или иначе

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

MC>>Отнюдь. На этом, собственно, все и работает. Один вызов ввода-вывода — одно и только одно уведомление.

P>кабы так зачем тогда GetQueuedCompletionStatus() второй параметр :

P>lpNumberOfBytes
P>[out] Pointer to a variable that receives the number of bytes transferred during an I/O operation that has completed.

P>если всегда одно срабатывание на один инициатор отсылки/приема ?
P>можно было бы думать, что на случай когда частичная отсылка — результат отказа на транспорте и нам надо знать что таки ушло (зачем ??) ,

Именно для этого. Только больше не для write/send, а для read/recv. Там необходимость этого параметра, надеюсь, очевидна.

P>но таки это нигде не сказано,

Про возможность чтения/записи меньшего количества байт, нежели запрошено, сказано в описании любой функции ввода-вывода.

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

Когда Вы взлетаете на самолете, тоже рассчитываете сесть несколько раз, если лететь далеко?

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

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

MC>>>Отнюдь. На этом, собственно, все и работает. Один вызов ввода-вывода — одно и только одно уведомление.

P>>кабы так зачем тогда GetQueuedCompletionStatus() второй параметр :

P>>lpNumberOfBytes
P>>[out] Pointer to a variable that receives the number of bytes transferred during an I/O operation that has completed.

P>>если всегда одно срабатывание на один инициатор отсылки/приема ?
P>>можно было бы думать, что на случай когда частичная отсылка — результат отказа на транспорте и нам надо знать что таки ушло (зачем ??) ,

MC>Именно для этого. Только больше не для write/send, а для read/recv. Там необходимость этого параметра, надеюсь, очевидна.

P>>но таки это нигде не сказано,

MC>Про возможность чтения/записи меньшего количества байт, нежели запрошено, сказано в описании любой функции ввода-вывода.

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

MC>Когда Вы взлетаете на самолете, тоже рассчитываете сесть несколько раз, если лететь далеко?

ок, спасибо!!, Михаил я все-таки не поленюсь и вкатаю строчку логирования для ситуации порциональной отсылки посредством WSASend в несолько срабатываний GetQueuedCompletionStatus(), модуль (смс-рассылка) плотно работает круглосуточно и мож когда порадует а я тогда вас порадую