hvladБерём любую ф-цию АПИ. Она пакует параметры, вызывает send и .... что дальше ?
Ждёт ответа ? Но ведь recv вызывается в другом потоке. Тогда что же она ждёт ? Сигнала от
этого другого потока ? А чем это лучше ожидания в recv ?
Ну, закладываясь на максимальный случай: эта функция помещает некоторый блок в некоторый
список, в этом блоке есть хэндл event-а или адрес callback-функции, который и используется
принимающим потоком после того как он положил в этот же блок адрес буфера с пришедшим
пакетом (как есть или уже распарсенным). После создания этого блока и отсылки пакета
функция может заниматься чем хочет, включая ожидание с таймаутом (буде какой-нибудь чудик
таковой запросит), немедленный возврат в вызывающий код (буде она из пока не существующего
асинхронного API) или что фантазия позволит. Получила сигнал - берёт из блока пришедший
пакет, удаляет блок из списка и завершается, все счастливы. (ЕМНИП, именно так и работает
лок-менеджер, только тот ждёт совсем не сетевые пакеты.)

hvladБерём сервер приложений. Да, есть такие приложения, у которых вполне легально
могут быть десятки и даже сотни хорошо нагруженных коннектов. Единый поток, работающий с
сетью, сразу станет бутылочным горлышком.
Ну, поздравляю, ты сам нашёл аргумент за создание отдельного потока на каждый коннект.
(Что я и предлагал.)

hvladНо у нас есть дополнительные сложности на пути к нему:
- в каждой ОСи соотв. АПИ не просто разное, а кардинально разное (по памяти - IOCP, epoll,
kqueue)

- По счастью код этого потока не обязан собираться для всех ОСей из одного исходника
- Старый добрый, имеющийся везде, select() имеет проблему с производительностью только
если ему пихают много хэндлов, чего при системе "выделенный поток на каждый коннект" нет.

hvlad- в некоторых ОСях такого АПИ вообще нет
Назови OS где нет select().

hvlad- сочетать разные транспорты (протоколы) в едином диспетчере тоже не так
просто
И по счастью не нужно. Дело диспетчера - унифицировать список блоков ожидания. Каждый
транспорт может обрабатываться разными функциями, благо коннект (и связанный с ним
служебный поток) использует только один транспорт.
Posted via ActualForum NNTP Server 1.5

hvladПоток на коннект - это последнее, что я буду рассматривать.
А зря, поскольку это простейший (а стало быть надёжнейший) вариант и рассматривать любые
другие стоит только после того, как будет доказано, что он не справится. KISS. Не будешь
усложнять задачу - не придётся ломать голову над решением.

hvladНу и подумай ещё о том, что 100 потоков, сидящих в select - это 100 вызовов
ядра и 200 переключений контекста (если ты понимаешь, о чём я).

Это переключения в один конец. Вызовы не вернутся, пока не будет необходимости. Надеюсь,
тебе не придёт в голову дурная идея для ожидания таймаута коннекта поставить таймаут у
select в сотую долю секунды и каждый раз когда оно вернётся проверять текущее время...
Posted via ActualForum NNTP Server 1.5

hvladПростейший вариант мы уже имеем сейчас.
Правильно. И поскольку он не работает так как хочется, время рассмотреть простейший среди
оставшихся.

hvladНе, ты меня не понимаешь.
Естественно не понимаю: твои намёки слишком мудрёны. Насколько я знаю, потоки, висящие в
функциях ожидания, шедулером ОСи игнорируются и никаких переключений между контекстами не
происходит.
Posted via ActualForum NNTP Server 1.5

hvladЕсли есть что по таймаутам
По ним я уже
всё
сказал .
Posted via ActualForum NNTP Server 1.5