Сообщение Re[3]: Порты завершения и все что с ними связано от 20.05.2021 10:15
Изменено 20.05.2021 10:16 ononim
Re[3]: Порты завершения и все что с ними связано
O>>На всякий случай отвечу на вопрос типа 'а зачем он мне его возвращает я ведь его сам знаю?' — затем что если вы запустили 100500 параллельных WSASend, по этому указателю вы сможете понять к какому именно из них относится этот результат.
O>Вообще соответствие пакета, который мы достали из очереди с помощью GetQueuedCompletionStatus — и одного из 100500 параллельных WSASend — идентифицируется через CompletionKey.
CompletionKey ассоциирован с файлом, а не с операцией. И если вы запускаете не более одной операции над файлом — это не значит что их можно запустить 1000500. Или запустить одновременно WSASend и WSARecv.
O>А поэтому вопрос остается, зачем тогда передавать адрес указателя на структуру WSAOVERLAPPED, чтобы в итоге получить ее адрес
, если Вы сами говорите, что "внутреннее назначение полей WSAOVERLAPPED — недокументированные вещи напрямую их ковырять не стоит" и идентификация пакета и вызова WSASend определяется через CompletionKey, а кол-во отравленных или принятых байт определяется через второй параметр функции GetQueuedCompletionStatus.
См выше.
O>Вообще соответствие пакета, который мы достали из очереди с помощью GetQueuedCompletionStatus — и одного из 100500 параллельных WSASend — идентифицируется через CompletionKey.
CompletionKey ассоциирован с файлом, а не с операцией. И если вы запускаете не более одной операции над файлом — это не значит что их можно запустить 1000500. Или запустить одновременно WSASend и WSARecv.
O>А поэтому вопрос остается, зачем тогда передавать адрес указателя на структуру WSAOVERLAPPED, чтобы в итоге получить ее адрес
, если Вы сами говорите, что "внутреннее назначение полей WSAOVERLAPPED — недокументированные вещи напрямую их ковырять не стоит" и идентификация пакета и вызова WSASend определяется через CompletionKey, а кол-во отравленных или принятых байт определяется через второй параметр функции GetQueuedCompletionStatus.
См выше.
Re[3]: Порты завершения и все что с ними связано
O>>На всякий случай отвечу на вопрос типа 'а зачем он мне его возвращает я ведь его сам знаю?' — затем что если вы запустили 100500 параллельных WSASend, по этому указателю вы сможете понять к какому именно из них относится этот результат.
O>Вообще соответствие пакета, который мы достали из очереди с помощью GetQueuedCompletionStatus — и одного из 100500 параллельных WSASend — идентифицируется через CompletionKey.
CompletionKey ассоциирован с файлом, а не с операцией. И если вы запускаете не более одной операции над файлом — это не значит что их нельзя запустить 1000500. Или запустить одновременно WSASend и WSARecv.
O>А поэтому вопрос остается, зачем тогда передавать адрес указателя на структуру WSAOVERLAPPED, чтобы в итоге получить ее адрес
, если Вы сами говорите, что "внутреннее назначение полей WSAOVERLAPPED — недокументированные вещи напрямую их ковырять не стоит" и идентификация пакета и вызова WSASend определяется через CompletionKey, а кол-во отравленных или принятых байт определяется через второй параметр функции GetQueuedCompletionStatus.
См выше.
O>Вообще соответствие пакета, который мы достали из очереди с помощью GetQueuedCompletionStatus — и одного из 100500 параллельных WSASend — идентифицируется через CompletionKey.
CompletionKey ассоциирован с файлом, а не с операцией. И если вы запускаете не более одной операции над файлом — это не значит что их нельзя запустить 1000500. Или запустить одновременно WSASend и WSARecv.
O>А поэтому вопрос остается, зачем тогда передавать адрес указателя на структуру WSAOVERLAPPED, чтобы в итоге получить ее адрес
, если Вы сами говорите, что "внутреннее назначение полей WSAOVERLAPPED — недокументированные вещи напрямую их ковырять не стоит" и идентификация пакета и вызова WSASend определяется через CompletionKey, а кол-во отравленных или принятых байт определяется через второй параметр функции GetQueuedCompletionStatus.
См выше.