Приветствую.Стоит задача принимать и обслуживать несколько соединений одновременно. Думаю что fork() в таком случае не годится.
В каком направлении копать?
Спасибо.
>Приветствую.
>
>Стоит задача принимать и обслуживать несколько соединений одновременно. Думаю что fork() в
>таком случае не годится.
>
>В каком направлении копать?
>
>Спасибо.Есть куча вариантов ... Например неблокируемый сокет, пул соединений,select (то что реализовывал я)
>Есть куча вариантов ... Например неблокируемый сокет, пул соединений,select (то что реализовывал
>я)В доках пишут что неблокируемый сокет не есть гуд (overhead на процессор), select() cейчас читаю, пока не все понял. А что вы имели в виду под пулом соединений? (poll() как альтернатива select()'у ? )
Если несложно - приведите небольшой пример с селектом для обслуживания нескольких сокетов.
Спасибо.
>>Есть куча вариантов ... Например неблокируемый сокет, пул соединений,select (то что реализовывал
>>я)
>
>В доках пишут что неблокируемый сокет не есть гуд (overhead на процессор),
>select() cейчас читаю, пока не все понял. А что вы имели
>в виду под пулом соединений? (poll() как альтернатива select()'у ? )
>
>
>Если несложно - приведите небольшой пример с селектом для обслуживания нескольких сокетов.
>
>
>Спасибо.Закажи себе http://www.ozon.ru/context/detail/id/1390985/
Там все очень подробно расписано, все варианты их плюсы и минусы и т.д. и т.п.
Думаю, что fork() вполне сгодится, только это не лучший вариант. Одно из самых перспективных решений - threads.
>Думаю, что fork() вполне сгодится, только это не лучший вариант. Одно из
>самых перспективных решений - threads.Извините, но с чего это Вы взяли, что под никсы потоки лучше чем процессы?
Я писал сервера, которые как раз обслуживают несколько соединений одновременно, именно использую fork.
Может я в потемках скитался? Аргументируйте плз, почему на потоках сервера получаются лучше чем на процессах? Скиньте плз ссылку, где это написанно.
>>Думаю, что fork() вполне сгодится, только это не лучший вариант. Одно из
>>самых перспективных решений - threads.
>
>Извините, но с чего это Вы взяли, что под никсы потоки лучше
>чем процессы?
>
>Я писал сервера, которые как раз обслуживают несколько соединений одновременно, именно использую
>fork.
>Может я в потемках скитался? Аргументируйте плз, почему на потоках сервера получаются
>лучше чем на процессах? Скиньте плз ссылку, где это написанно.Молодой человек, THREADS лучше PROCESSES, если нужно работать с одними и теми же данными в нескольких контекстах исполнения. Это факт, какие ссылки? Programming with POSIX threads книгу можете почитать.
>>Думаю, что fork() вполне сгодится, только это не лучший вариант. Одно из
>>самых перспективных решений - threads.
>
>Извините, но с чего это Вы взяли, что под никсы потоки лучше
>чем процессы?
>
>Я писал сервера, которые как раз обслуживают несколько соединений одновременно, именно использую
>fork.
>Может я в потемках скитался? Аргументируйте плз, почему на потоках сервера получаются
>лучше чем на процессах? Скиньте плз ссылку, где это написанно.
Пожалуйста, взгляните на http://cs.baylor.edu/~donahoo/practical/CSockets/textcode.html и http://www.cs.cf.ac.uk/Dave/C/node32.html#SECTION00327000000....
Не далее чем полгода назад я сам писал коммерческий сервер под Solaris с использованием кроссплатформенной(!!!) boost::thread.
почему это не сгодится? а как-же тогда все демоны работают?accept, а затем сразу fork (или в обратном порядке)
>почему это не сгодится? а как-же тогда все демоны работают?
>
>accept, а затем сразу fork (или в обратном порядке)
Советую, сначало аксепт, потом форк ;)
>>почему это не сгодится? а как-же тогда все демоны работают?
>>
>>accept, а затем сразу fork (или в обратном порядке)
>
>
>Советую, сначало аксепт, потом форк ;)да, это собственно вопрос и был :) я почему-то (начитавшись книжек наверно) всегда именно так и делал accept, а затем fork.
Но тут мне пришла в голову мысля - а почему-бы не сделать в обратном порядке (только в дочернем процессе) или в этом случае запрос на соединение так и останется у родителя непринятым?
>>>почему это не сгодится? а как-же тогда все демоны работают?
>>>
>>>accept, а затем сразу fork (или в обратном порядке)
>>
>>
>>Советую, сначало аксепт, потом форк ;)
>
>да, это собственно вопрос и был :) я почему-то (начитавшись книжек наверно)
>всегда именно так и делал accept, а затем fork.
>
>Но тут мне пришла в голову мысля - а почему-бы не сделать
>в обратном порядке (только в дочернем процессе) или в этом случае
>запрос на соединение так и останется у родителя непринятым?ты уж определись, в каком процессе будешь принимать соединения, в родительском или дочернем? :)
я бы все таки принимал соединения в родительском и это логично, а уж в дочернем процессе работал с клиентом...
>ты уж определись, в каком процессе будешь принимать соединения, в родительском или
>дочернем? :)
>я бы все таки принимал соединения в родительском и это логично, а
>уж в дочернем процессе работал с клиентом...подумав еще немного я понял что сморозил какую-то чушь. буду делать и дальше как делалал :)
>подумав еще немного я понял что сморозил какую-то чушь.Почему чушь? Так prefork-сервера работают.
>>подумав еще немного я понял что сморозил какую-то чушь.
>
>Почему чушь? Так prefork-сервера работают.в этом случае только один из деток ждет входещее соединение?
>>>подумав еще немного я понял что сморозил какую-то чушь.
>>
>>Почему чушь? Так prefork-сервера работают.
>
>в этом случае только один из деток ждет входещее соединение?Процесс-мастер передает сокеты потомкам через sendmsg.
>в этом случае только один из деток ждет входещее соединение?Как напишешь.
Смотри про accept serialization http://httpd.apache.org/docs/misc/perf-tuning.html
Попахивает пионерией...
>почему это не сгодится? а как-же тогда все демоны работают?
>
>accept, а затем сразу fork (или в обратном порядке)как я понимаю fork() достаточно тяжелая операция, и для определенных задач (например одновременно 5000 соединений) не годится.
>>почему это не сгодится? а как-же тогда все демоны работают?
>>
>>accept, а затем сразу fork (или в обратном порядке)
>
>как я понимаю fork() достаточно тяжелая операция, и для определенных задач (например
>одновременно 5000 соединений) не годится.согласен, форк тяжелая операция, но за то более безопасная, чем к примеру потоки...
был, случай, когда сервер писался использую потоки...только он жил недолго, порядка недели, и потом мирно померал...причина, до сих пор неясна, видимо это специфика потоков, а может еще что-то...утечки памяти вроде все убрали, но все равно сервер жил недолго...Плюнули на потоки, переписали используя процессы...все ок, сервер живет и не падает, утечки памяти и др. проблеммы пофиг, все равно дочерние процессы мирно умирают, когда отработает комманды клиентов, и вроде ничего страшного нет в процессах...
Есть еще такое мнение, пока не понял, откуда оно пришло, просто слышал звон, что под юниксы лучше использовать процессы, под виндос потоки! Если у кого есть инфа, по этому вопросу, скиньте...
>Есть еще такое мнение, пока не понял, откуда оно пришло, просто слышал
>звон, что под юниксы лучше использовать процессы, под виндос потоки! Если
>у кого есть инфа, по этому вопросу, скиньте...Потому-что в винде для начала нет форка, и порождение нового процесса - это действительно целая история. А новый поток создается довольно легко.
Планировщик в винде работает именно с потоками.В линуксе (а как в других - не знаю) потоки это фактически процессы. И никакого особого выигрыша от их использования нет.
>>Есть еще такое мнение, пока не понял, откуда оно пришло, просто слышал
>>звон, что под юниксы лучше использовать процессы, под виндос потоки! Если
>>у кого есть инфа, по этому вопросу, скиньте...
>
>Потому-что в винде для начала нет форка, и порождение нового процесса -
>это действительно целая история. А новый поток создается довольно легко.
>Планировщик в винде работает именно с потоками.
>
>В линуксе (а как в других - не знаю) потоки это фактически
>процессы. И никакого особого выигрыша от их использования нет.В виндах есть подобие форка, CreateProcess кажись, и там не такая уж длинная история...Но только в виндах почему-то стараются не использовать виндовый форк , а пользуются потоками...ну и флаг им в руки...
А процесс создал, поюзал его и убил, никакой головной боли, а вот потоки...надо корректно их прибить, что не всегда получается, следить за памятью и т.п.
ИМХО, лучше использовать процессы, дабы потом полгода не думать, почему все так плохо работает.Потоки в линуксе и не в линуксе не есть процессы, совсем по другому организуется память!
CreateProcess - это сразу fork+exec, т.е. новый процесс будет порожден "с нуля", а не как копия родительского. Когда в винде появится fork то это будет уже не винда, *NIX :) Поэтому в винде и используют только потоки.
>Потоки в линуксе и не в линуксе не есть процессы, совсем по
>другому организуется память!А о каких, собственно, потоках мы говорим? User-space или Kernel-space? И о какой реализации? Там их штук 5, или больше. И все реализации различны.
>Приветствую.
>
>Стоит задача принимать и обслуживать несколько соединений одновременно. Думаю что fork() в
>таком случае не годится.
>
>В каком направлении копать?
>
>Спасибо.Кто такую глупость сказал, что fork не годится?
>Стоит задача принимать и обслуживать несколько соединений одновременно. Думаю что fork() в
>таком случае не годится.
>
>В каком направлении копать?fido7.ru.unix.prog: FAQ appendix 1: как писать сервера
http://groups.google.com/groups?selm=200506020714.j527E0f502...