> неблокирующий сокет - зло

Зло, бес с порно.
Сокетные компоненты (по кр.м., в исполнении борманда) -- ещё большее зло.


> Притчу про "всякий овощ .." помнишь ?)

Это не овощ, это сорняк-мутант.

> > неблокирующий сокет - зло
>
> Зло, бес с порно.

Почему зло?

И не надо путать неблокирущие и асинхронные сокеты. Это не одно и то же.

> Сокетные компоненты (по кр.м., в исполнении борманда) --
>  ещё большее зло


"Вы не любите кошек ? Да вы просто не умеете их готовить !" (С)


> это сорняк-мутант


Ну да.

А аргументы, конечно же, - "наследие царского режима")

> DVM ©   (03.10.07 15:38) [21]
> Почему зло?

Потому что, как тут верно, но не полно вспомнили, "наследие царского режима".


> DVM ©   (03.10.07 15:39) [22]
> И не надо путать неблокирущие и асинхронные сокеты. Это
> не одно и то же.

Не напомнишь, кто, где и когда утверждал, что это одно и то же?


> Сергей М. ©   (03.10.07 15:49) [23]
> "Вы не любите кошек ? Да вы просто не умеете их готовить
> !" (С)

Я так понял, это был Аргумент?


> А аргументы, конечно же, - "наследие царского режима")

Не затруднит напомнить полную версию текста, откуда ты отквоченное выдрал?
Как только сподобишься, получишь аргумент на "сорняк".
А "мутант" -- так это борландовское исполнение обёртки, к которой две основные претензии:

1. Мутное обращение с сущностями.
Не вводится никакой новой абстракции. Нафига объектная обёртка? Ладно, допустим, для батонокидательства. Но экономия трудоёмкости мизерная, объём рукописного кода соизмерим с прямым использованием WS API.
Смешиваются сущности. В блокирующем и неблокирующем режимах используются разные наборы методов (либо общие методы, но изобилующие if Block then ... else ...), это наводит на мысль о разных ветвях наследования.

2. Сокрытая сложность и неочевидные требования к окружению.
В неблокирующем режиме компоненты используют механизм оконных сообщений и, как следствие, требуют message pump. Эта зависимость от окружения не только не очевидна из публичного интерфейса классов, но даже не отражена в документации. Обнаружить эту особенность можно либо стукнувшись лбом (как в субже), либо зная детали реализации (тогда вопрос: нафиг нужны такие weak-incapsulated компоненты?).

> Потому что, как тут верно, но не полно вспомнили, "наследие
> царского режима".

Наследие это асинхронные сокеты на сообщениях, а не неблокирующие. А говорите, что не путаете. Неблокирующие сокеты ничем не хуже и не лучше блокирующих, были и есть и используются и в Unix и в Windows. А вот асинхронные сокеты на сообщениях - это изобретение MS для ранних версий Win (3.11), так как в них с многопоточностью было все не очень гладко.

Просто так сложилось, что в Windows асинхронные сокеты - это всегда неблокирующие сокеты, но неблокирующие сокеты - это не всегда асинхронные.

> DVM ©   (03.10.07 17:34) [25] [26]

Это всё понятно.
Только вот в компонентах под "неблокирующими" подразумеваются именно асинхронные сокеты на сообщениях.


> Просто так сложилось, что в Windows асинхронные сокеты -
>  это всегда неблокирующие сокеты

Ну, теперь уже не всегда. Есть ведь overlapped IO, что намного удобнее.

DiamondShark ©   (03.10.07 17:25) [24]
Я для себя сделал BlockScktComp - взял стандартный ScktComp и вырезал от туда всю асинхронику

> DiamondShark ©   (03.10.07 18:56) [27]


> Ну, теперь уже не всегда. Есть ведь overlapped IO, что намного
> удобнее.


В Windows всегда.
MSDN ioctlsocket


> The WSAAsyncSelect and WSAEventSelect functions automatically
> set a socket to nonblocking mode


Оно и понятно, что сокет должен быть неблокирующим. Иначе как бы мы могли вызвав recv, потом в этом же потоке подождать события функцией   WSAWaitForMultipleEvents, ибо висели бы на вызове recv, если сокет блокирующий.

> DiamondShark ©   (03.10.07 18:56) [27]


Хотя извиняюсь, в

> Evgeny V ©   (04.10.07 07:06) [29]

я наврал. С оверлаппед сокетами все сложнее. Просто подзабыл что EventSelect и overlapped сокеты это разное:-)

Доброе время суток всем, борюсь со следующей проблемой:
TServerSocket работает в блокирующем режиме, создал своего наследника для потока TServerClientThread. В ClientExecute вертится следующий цикл (прошу прощения что BCB):

while (!Terminated && ClientSocket->Connected)
{
.....
}

Цикл работает отлично, но при отключении клиента НЕ ЗАВЕРШАЕТСЯ!, никак не соображу почему.
Как можно узнать что клиент отключился?

P.S. Клиент не мой, переписать не смогу, протокола не знаю. :-)