(Berkeley-style sockets) Корректный выход из блокирующего accept.

← →
GuAV © (2006-01-19 15:54) [0]

В дополнительном потоке функция accept ожидает подключения к сервер-сокету, при подключении добавляет его в множество подключённых (с соотв. синхронизацией, разумеется) и ждёт нового клиента. Как корректно завершить такое ожидание ?

Мои варианты:
1. CloseSocket из основного потока. Работает, accept завершается с ошибкой, но я не нашел где бы это было документировано.
2. WSACancelBlockingCall, но "This function has been removed in compliance with the Windows Sockets 2 specification" © MSDN
3. Перенести это дело в GUI поток, опрашивать через select с нулевым таймером. Эта идея мне однако не нравится, т.к. сообщения могут приходить недостаточно часто, дополнительный таймер с небольшим интервалом - излишняя загрузка системы.
4. Периодический select с интервалом в доп потоке, проверка флага завершения - тогда доп поток может завершиться долго.
5. Жать accept и чего-либо ещё (например сообщений). Но как ?

Думаю, вопрос понятен..

← →
Digitman © (2006-01-19 16:35) [1]

Решение очевидно - переход на реализацию сабжа в неблокирующем режиме, там где отмена асинхронных операций вполне документирована.

← →
GuAV © (2006-01-19 17:01) [2]

Допустим, сокет переведен в неблокирующий режим, от accept получено INVALID_SOCKET, WSAGetLastError = WSAEWouldBlock. Когда препринимать следующую попытку accept ?

← →
Digitman © (2006-01-19 17:25) [3]

> Когда препринимать следующую попытку accept ?

Тогда когда ты получишь асинхронно возбуждаемое (и ожидаемое тобой) FD_ACCEPT-событие.

← →
GuAV © (2006-01-19 18:54) [4]

Понял. Спасибо.

← →
Rouse_ © (2006-01-19 22:29) [5]

> GuAV ©

Сколько работаю с сетью, первый раз слышу чтобы кто-то поймал WSAEWOULDBLOCK на accept при асинхронке...
Не путай неблокирующий и асинхронный режим транспорта...

← →
Digitman © (2006-01-20 08:35) [6]

> Rouse_ © (19.01.06 22:29) [5]

Ну здрасти приехали !

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

Сейчас мы, думаю, не говорим об overlapped-режиме, это особый случай, сочетающий в себе поведение транспорта, характерное как для блок. так и и для неблок. режимов.

← →
Rouse_ © (2006-01-20 12:33) [7]

> Разве не так ?

Так.

← →
GuAV © (2006-01-20 17:06) [8]

> Rouse_ © (19.01.06 22:29) [5]
> Сколько работаю с сетью, первый раз слышу чтобы кто-то
> поймал WSAEWOULDBLOCK на accept при асинхронке...

Когда я писал [2], я ещё подразумевал простой неблокирующий режим, без WSAAsyncSelect/WSAEventSelect .

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

ps: таки сделал один поток и через сообщения. вроде работает.

> таки сделал один поток и через сообщения. вроде работает

Можно и не "через сообщения" (WSAAsyncSelect).
Можно и "через события" (WSAEventSelect).
Суть не меняется - ты переводишь работу транспорта в неблок.режим с асинхронной нотификацией тем или иным образом. Логика возникновения при [WSA]Accept WSAEWOULDBLOCK-отказа едина и там и там и строго регламентирована в MSDN.

> Скорее всего, нельзя поймать WSAEWOULDBLOCK на accept при
> вызове accept для события/сообщения FD_ACCEPT, поэтому Вам
> такие случаи неизвестны.

Я именно про это и говорю, что по приходу FD_ACCEPT никогда не слышал о WSAEWOULDBLOCK при вызове accept/WSAAccept

А что вы можете сказать про TTcpClient/TTcpServer ?
Насколько я понял, асинхронного и overlapped режимов там нет, только блокирующий и неблокирующий. В каком режиме и когда их обычно применяют ? Делают ли они работу с сокетами более удобной ?

(Berkeley-style sockets) Корректный выход из блокирующего accept. Найти похожие ветки