Что эффективнее - потоки или неблокирующие сокеты и poll()?

Это, типа, шутка?

Типа, нет :) А что здесь смешного ?

> А что здесь смешного ?

Не совсем непонятно, что автор топика имеет в виду под термином "потоки". Ремарка "На однопроцессорной машине" позволяет сделать вывод, что речь идет о нитях (threads), а вопрос стоит так: "Что эффективнее, обрабатывать каждое соединение в отдельной нити, или ограничится однонитевым процессом и обрабатывать запросы на соединение по мере поступления?". Впрочем, возможны варианты (много), и совершенно непонятно, почему автор хочет _одновременно_ использовать неблокирующие сокеты и poll().

К састью, ответ в любом случае будет однозначным: вариант с poll() на однопроцессорной машине будет эффективнее.

:-)

Спасибо. Просто я еще только берусь за это, и не совсем точно выражаюсь в терминологии. Да, мне нужно обрабатывать "конкурентные" соединения (типа вкб сервера), и вот думаю, лучше для каждого соединения запускать нить, или использовать poll(). Спасибо за ответ на мой вопрос. P.S. А в соучае двупроцессорной машины - лучше на каждый процессор по ните? Ну и в каждой нити - poll()?

> Не совсем непонятно, что автор топика имеет в виду под термином "потоки". Ремарка "На однопроцессорной машине" позволяет сделать вывод, что речь идет о нитях (threads)

Оффтоп конечно, но вроде бы автор темы удовлетворился ответом, так что можно :))

Разве в российской литературе не переводят thread как поток [исполнения]? Если нет, то откуда тогда взялся термин "многопоточный"?

Будь проще, Die-Hard. ;)

> Да, мне нужно обрабатывать "конкурентные" соединения (типа вкб сервера), и вот думаю, лучше для каждого соединения запускать нить, или использовать poll(). P.S. А в соучае двупроцессорной машины - лучше на каждый процессор по ните? Ну и в каждой нити - poll()?

Есть неплохая статейка про программирование scaleable серверов. Правда она про яву... но, я думаю, если написать эту же статью, но для C, отличия будут только в примерах кода.

Вот она: http://www.onjava.com/lpt/a/5127

Полезная для C программиста информация начинается с заголовка "Threading in a Multiplexed World".

Спасибо за линк. Т.е. как я понял - лучше сделать несколько потоков "работников" и один упавляющий, а в "работниках" использовать poll(). Думал о таком, попробую реализовать.

2anonymous (*) (09.09.2005 9:31:44):

> Разве в российской литературе не переводят thread как поток [исполнения]?

Переводят (к сожалению).

Перевод thread как поток, очевидно, совершенно неудачен (ввиду жуткой перегруженности термина "поток"). Он обязан своим происхождением неблагозвучности перевода термина "multithreaded" как "многонитяной" или "многонитевой" ("многопоточный" звучит гораздо лучше).

Термин "поток" в российской литературе явно перегружен: помимо потоков исполнения есть близкие по смыслу потоки управления; в ЦеПП есть потоки, и в stdio есть потоки, и есть различные dataflows; наконец, имеется STREAMS -- популярная I/O архитектура, придуманная Деннисом Риччи. В контексте "потоки, неблокирующие сокеты, poll()" первое, что приходит в голову -- Риччевская STREAMS.

anonymous (*) (09.09.2005 9:40:47):

> Правда она про яву... но, я думаю, если написать эту же статью, но для C, отличия будут только в примерах кода.

IMHO:

Тысячами плодить нити -- жабоспецифика. Именно от злоупотребления этим подходом и происходят главные Жабские тормоза.

Изначельно это задумывалось Сантехниками для масштабируемости на типичную Сантехнику и (будущие) тысячепроцессорные серверы. Ничего из этого не получилось, да и серверостроение пошло по несколько иному пути (ccNUMA вместо милого сердцу Сантехника бесконечного расширения шины), а Жаба осталась. Чтобы оно работало, пришлось даже в Линух засовывать MxN нити -- еще пару лет назад оно под Линуксом было нефункционально.

Злоупотребление userspace нитями -- не что иное, как закаммуфлированные вызовы функций где надо и не надо. Использование подобной технологии есть систематическое самонадувательство.

Все вышесказанное -- мое мнение, с которым очень многие не согласны.

Вдогонку --

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

> Тысячами плодить нити -- жабоспецифика. Именно от злоупотребления этим подходом и происходят главные Жабские тормоза.

В приведенной выше статье в том числе рассказывается о том, как в яве не плодить кучу нитей, в ней уже давно есть "неблокирующие сокеты" (терминология, я надеюсь, правильная? ;])

anonymous (*) (09.09.2005 19:33:31)

Дык, правильная статья-то, я ж оговорился! Просто медицинский факт: "жабобыдлокодеры" частенько злоупотребляют кол-вом одновременно бегущих нитей.

> ...в ней уже давно есть "неблокирующие сокеты"...

Во-первых, недавно.

Во-вторых, необходимость в неблокирующих сокетах в Жабе проистекала как раз ввиду отсутствия нормальных механизмов типа poll() или select().

Неблокирующие дескрипторы нужны в _очень_ редко встречающихся специфических ситуациях. Как правило, они вообще не нужны, если есть poll() или select().