Испытал такой код. Программа создает n тредов вида:

void *thread_function(void *sock)
for(;;) {
accept((int)sock);
...
}

Все accept'ы слушают один и тот же сокет.
Как ни странно, оно работает. Всмысле того, что accept реально принимает соединение из активного в данный момент времени треда (естественно при условии, что он уже обработал соединение и снова "застрял" на accept'е).
Вопрос: в чем ошибка? Насколько я понимаю, так делать нельзя. По крайней мере подобной реализации сервера я не нашел.

• accept() и pthread на FreeBSD,DeadMustdie, 18:39 , 13-Мрт-06
  • accept() и pthread на FreeBSD,Dip, 10:32 , 14-Мрт-06
    • accept() и pthread на FreeBSD,DeadMustdie, 17:36 , 14-Мрт-06
• accept() и pthread на FreeBSD,Николас, 05:36 , 14-Мрт-06
  • accept() и pthread на FreeBSD,Dip, 10:34 , 14-Мрт-06
    • accept() и pthread на FreeBSD,DeadMustdie, 17:38 , 14-Мрт-06
      • accept() и pthread на FreeBSD,Dip, 09:36 , 15-Мрт-06
        • accept() и pthread на FreeBSD,DeadMustdie, 10:28 , 15-Мрт-06
• accept() и pthread на FreeBSD,kir, 20:07 , 16-Мрт-06

>Испытал такой код. Программа создает n тредов вида:
>
>void *thread_function(void *sock)
>for(;;) {
> accept((int)sock);
> ...
>}
>
>Все accept'ы слушают один и тот же сокет.
>Как ни странно, оно работает. Всмысле того, что accept реально принимает соединение
>из активного в данный момент времени треда (естественно при условии, что
>он уже обработал соединение и снова "застрял" на accept'е).
>Вопрос: в чем ошибка? Насколько я понимаю, так делать нельзя. По крайней
>мере подобной реализации сервера я не нашел.

У accept()а больше параметров.

Кроме этого ничто не мешает программе правильно работать, насколько я понимаю.
Тем не менее, на практике такое делают весьма редко, поскольку смысла особого
в том нету. Эффекта от дополнительного распараллеливания здесь практически
не будет, так как handshake ядро обычно делает до постановки соединения
в очередь на оный accept().

Хотя если действительно сервер обрабатывает множество короткоживущих соединений,
вариант вполне работоспособный. Сама схема коротких коннектов довольно тормозная,
об этом нужно помнить. Высоколатентные сети не редкость, и в них такой софт
будет очень плохо себя чувствовать.

>У accept()а больше параметров.
Я для наглядности все упростил. Не надо воспринимать этот текст как кусок С кода.

>Кроме этого ничто не мешает программе правильно работать, насколько я понимаю.
>Тем не менее, на практике такое делают весьма редко, поскольку смысла особого
>в том нету. Эффекта от дополнительного распараллеливания здесь практически
>не будет, так как handshake ядро обычно делает до постановки соединения
>в очередь на оный accept().
Частично понял. Буду читать про handshake. Может тогда все пойму.

>Хотя если действительно сервер обрабатывает множество короткоживущих соединений,
>вариант вполне работоспособный. Сама схема коротких коннектов довольно тормозная,
>об этом нужно помнить. Высоколатентные сети не редкость, и в них такой
>софт будет очень плохо себя чувствовать.

По идее будут устанавливаться короткие соединения с разными клиентами, т.е. запросов много, но все от разных хостов. А повторные - с достаточно большими интервалами. Так что хранить открытое соединение смысла нет. Вообще ближайшее к моим условиям решение - это что-то вроде dns, может ldap, но на счет последнего я не очень уверен. Интересно было бы узнать, как работают они. Но исходники bind'а я не осилил.

>на счет последнего я не очень уверен. Интересно было бы узнать,
>как работают они. Но исходники bind'а я не осилил.

В DNS используется не TCP, а UDP с вручную сделанными повторами/подтверждениями.
Соответственно затрат на установление соединения нэма.

>Вопрос: в чем ошибка? Насколько я понимаю, так делать нельзя. По крайней
>мере подобной реализации сервера я не нашел.

Почему нельзя? Если работает и не глючит то можно

>
>>Вопрос: в чем ошибка? Насколько я понимаю, так делать нельзя. По крайней
>>мере подобной реализации сервера я не нашел.
>
>Почему нельзя? Если работает и не глючит то можно

В том то и дело, что у меня нет уверенности в том, что не глючит. Может оно именно в моих условиях не глючит. А испытывать в "боевых" пока нет возможности.

>В том то и дело, что у меня нет уверенности в том,
>что не глючит. Может оно именно в моих условиях не глючит.
>А испытывать в "боевых" пока нет возможности.

Говорю же, всё корректно, работать будет. Но схема необычная, так редко делают.

>>В том то и дело, что у меня нет уверенности в том,
>>что не глючит. Может оно именно в моих условиях не глючит.
>>А испытывать в "боевых" пока нет возможности.
>
>Говорю же, всё корректно, работать будет. Но схема необычная, так редко делают.

Это радует. Но я все-таки так и не понял, в чем тут собака зарыта... Реализация вроде очень простая, че так не делают?
В общем спасибо, поумнел я за последние несколько дней сильно :)

>Реализация вроде очень простая, че так не делают?

Простая реализация достаточно тормозной схемы. Плюс при подключении
клиента часто надо всякие ресурсы выделить, в протокол запись кинуть, то-сё.
А в этой схеме все эти действия сопряжены с необходимостью захвата блокировок,
что довольно-таки неудобно.

  ошибки дествительно нет,
  до такой реализации вы пришли исходя из своих познаний и незнаний о том как работает сама OC система итд - поэтому совет - совершенствуйте свои познания