Здравствуйте, netch80, Вы писали:

N>P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.
Не знаю как там под юниксами, но под виндами — либо, в простейшем случае, по потоку на клиента, либо IOCP. Все остальное вредно для здоровья и душевного равновесия. А то, что в юниксах такой зоопарк — разработчикам можно только посочувствовать, и пожелать скорейшего перехода на единую нормальную технологию.

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:

N>>P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.
G>Не знаю как там под юниксами, но под виндами — либо, в простейшем случае, по потоку на клиента, либо IOCP. Все остальное вредно для здоровья и душевного равновесия. А то, что в юниксах такой зоопарк — разработчикам можно только посочувствовать, и пожелать скорейшего перехода на единую нормальную технологию.

Т.е. если я запущу сервер на Эрланг с числом потоков по числу ядер, то это вредно для здоровья и моего душевного равновесия? Или вот, когда я работал в конторе, где писали софт для телекома на Java, и оно вполне работало на винде, не беря по потоку на коннект — это тоже было себе и клиентам назло?
(виндовые машины были у разработчиков, хоть и не у всех, в реальных условиях оно не на винде работало, конечно)

Здравствуйте, Курилка, Вы писали:

К>Т.е. если я запущу сервер на Эрланг с числом потоков по числу ядер, то это вредно для здоровья и моего душевного равновесия? Или вот, когда я работал в конторе, где писали софт для телекома на Java, и оно вполне работало на винде, не беря по потоку на коннект — это тоже было себе и клиентам назло?
К>(виндовые машины были у разработчиков, хоть и не у всех, в реальных условиях оно не на винде работало, конечно)
Ты о чем вообще? Вот это все хозяйство внутри себя что использует?

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:

К>>Т.е. если я запущу сервер на Эрланг с числом потоков по числу ядер, то это вредно для здоровья и моего душевного равновесия? Или вот, когда я работал в конторе, где писали софт для телекома на Java, и оно вполне работало на винде, не беря по потоку на коннект — это тоже было себе и клиентам назло?
К>>(виндовые машины были у разработчиков, хоть и не у всех, в реальных условиях оно не на винде работало, конечно)
G>Ты о чем вообще? Вот это все хозяйство внутри себя что использует?

На пальцах объясняю: ни Эрланг, ни JVM не создают по потоку на клиента и не используют IOCP. У эрланга (как я уже писал) создаётся по потоку на ядро, в JVM (в том сервере) создаётся конечное число потоков (определяемое конфигурацией и, скорее всего также, соответсвующее числу ядер)

Здравствуйте, Курилка, Вы писали:

К>На пальцах объясняю: ни Эрланг, ни JVM не создают по потоку на клиента и не используют IOCP.
А что они используют? И почему они не используют IOCP?

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:

К>>На пальцах объясняю: ни Эрланг, ни JVM не создают по потоку на клиента и не используют IOCP.
G>А что они используют? И почему они не используют IOCP?
Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.

Здравствуйте, Курилка, Вы писали:

К>Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.
Причем тут потоки? С сокетами какая модель работы?

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:

К>>Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.
G>Причем тут потоки? С сокетами какая модель работы?

если про сокеты, то, видимо, ты будешь прав, только всё равно эрланг не использует IOCP (но используется epoll, /dev/poll etc.), но причина, видимо, в том, что люди виндой не пользуются/

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:

К>>Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.
G>Причем тут потоки? С сокетами какая модель работы?

Сокет посылает сообщение процессу-владельцу, как только в него поступают данные. Остановить это, кстати, AFAIK нельзя:) Насколько это похоже на IOCP, судите сами;) Или речь о том, что там внутри? В виндовом варианте может быть и IOCP, но прикладному программисту эти тонкости не видны.

Здравствуйте, Курилка, Вы писали:

К>если про сокеты, то, видимо, ты будешь прав,
Дык это в моем первом сообщении и было. Это ж очевидно

К>только всё равно эрланг не использует IOCP (но используется epoll, /dev/poll etc.), но причина, видимо, в том, что люди виндой не пользуются/

Здравствуйте, netch80, Вы писали:

N>Или речь о том, что там внутри?
Не понимаю о чем разговор, в моем сообщении всё (всё) очевидно Да, внутри.

Здравствуйте, Sinclair, Вы писали:

VD>>IIS вроде бы выделяет, но все им пользуются тем не менее.
S>Ну конечно же ничего он не выделяет. Он использует IO Completion Ports и пул потоков.

И что в итоге выходит на одного активного клиента?

Здравствуйте, VladD2, Вы писали:

VD>И что в итоге выходит на одного активного клиента?

Запусти ProcessExplorer, и посмотри, сколько тредов у процесса system имеет стартовый адрес в http.sys (по крайней мере один из них — сборщик мусора).

Приложениям же достаточно одного треда на очередь HTTP запросов. Одна очередь способна обрабатывать запросы к нескольким URL от (почти) произвольного количества клиентов.

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:

N>>Или речь о том, что там внутри?
G>Не понимаю о чем разговор, в моем сообщении всё (всё) очевидно ;) Да, внутри.

Не очевидно.
Erlang создавался на embedded платформе Unix стиля и до сих пор активно на винду не переносился. Может, сейчас начнут.

Здравствуйте, sluge, Вы писали:

S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?

Попробую высказать крамольную мысль. Если програмировать в терминах "пускать эту задачу в отдельном потоке или нет" то далеко не уедешь. Не получишь по настоящему масштабируемую систему. Не сможешь запустить как на winCE так и на высоконагруженном сервере.

А если думать о решаемой задаче в отрыве от к-ва потоков? пускай к-вом потоков заведует кто то другой, конфиг например. А нам то зачем закладываться на то в каком мы потоке крутимся? Собственно знание о том в каком мы потоке и без того увеличивает связанность данных.

Вывод : ответь себе на вопрос, а стоит ли в прикладном коде каким бы то ни было способом закладываться на исполняющий поток ?

Здравствуйте, netch80, Вы писали:

N>Не очевидно.
КАК НАМ ВСЕМ НАУЧИТЬСЯ ЧИТАТЬ, ЧТО НАПИСАНО?

"Не знаю как там под юниксами, но под виндами — ..."

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:

N>>Не очевидно.
G>КАК НАМ ВСЕМ НАУЧИТЬСЯ ЧИТАТЬ, ЧТО НАПИСАНО?

G>"Не знаю как там под юниксами, но под виндами — ..."

"Я читал какой-то текст этого автора! Кажется, я знаю, что здесь написано!" (из Вашей же ссылки)

Что это были разные сообщения и в них может идти речь совершенно о разном — видите?

Здравствуйте, minorlogic, Вы писали:

M>Попробую высказать крамольную мысль. Если програмировать в терминах "пускать эту задачу в отдельном потоке или нет" то далеко не уедешь. Не получишь по настоящему масштабируемую систему. Не сможешь запустить как на winCE так и на высоконагруженном сервере.

M>А если думать о решаемой задаче в отрыве от к-ва потоков? пускай к-вом потоков заведует кто то другой, конфиг например. А нам то зачем закладываться на то в каком мы потоке крутимся? Собственно знание о том в каком мы потоке и без того увеличивает связанность данных.

M>Вывод : ответь себе на вопрос, а стоит ли в прикладном коде каким бы то ни было способом закладываться на исполняющий поток ?

К сожалению, стоит. Например, простейший случай — некое библиотечное средство работает только с той нитью, из которой его инициализировали. Мне приходится иметь дело с библиотеками доступа к базе данных, которые имеют такие ограничения. Или, например, в Erlang стандартной практикой является привязка ETS (хэш-таблицы в памяти) или порта (такого, как открытый сокет) к одному процессу, который назначен владельцем: только владелец порта имеет право писать в него и только он получает сообщения из него. Менять владельца иногда можно, но геморройно.

Это случай внешних ограничений, но даже без них достаточно часто оказывается ряд факторов внутреннего порядка. Опять-таки, если мы знаем, что с каким-то ресурсом работает только одна нить, можно сократить затраты на локинг. Я постоянно сталкиваюсь с проблемами подобного рода, но трудно сформулировать достаточно внятный пример, не зависящий от задачи.

Ваше предложение достаточно часто реализуется в том случае, если работу можно формализовать в терминах заданий и их исполнителей. Исполнителями назначаются пулы ниток, в конфиге выставляются настроечные параметры этих пулов (типа initial, max, min_spare, max_spare), и далее всё просто и прямолинейно — задание формулируется в виде сообщения, кладётся во входную очередь пула, дальше его отработают и сформируют другие сообщения, которые могут быть обработаны другими пулами. Разделяя типы заданий по пулам, можно подобрать адекватное разделение нагрузки по внутренним видам. Настраивая параметры, можно разрешать как безудержный рост, так и сильное лимитирование. Данные хранятся в общей памяти и блокируются стандартными механизмами. Под такую обстановку писать — крайне удобно и просто, вопросов нет:) Только FSM'ы нарисовать надо, если где-то внешнее ожидание.

Всё это я к тому, что "знание о том, в каком мы потоке" в Вашей терминологии почему-то приобрело дополнительное значение "в котором по счёту". Это действительно не важно, важно другое: например (простой, но понятный случай) знание и гарантия того, что нить, исполняющая какой-то код (1), не та же, что нить, исполняющая (2), независимо от того, как легли карты и что выдал генератор случайных чисел. В этом смысле "в каком мы потоке" крайне важно. Если нить A ждёт ответа на задание Y, которое отдано на вход очереди той же нити A, работы не будет. Если другой — будет.

(Несколько сумбурно описал, но идея должна быть понятна.)

Здравствуйте, netch80, Вы писали:

N>Ваше предложение достаточно часто реализуется в том случае, если работу можно формализовать в терминах заданий и их исполнителей. Исполнителями назначаются пулы ниток, в конфиге выставляются настроечные параметры этих пулов (типа initial, max, min_spare, max_spare), и далее всё просто и прямолинейно — задание формулируется в виде сообщения, кладётся во входную очередь пула, дальше его отработают и сформируют другие сообщения, которые могут быть обработаны другими пулами. Разделяя типы заданий по пулам, можно подобрать адекватное разделение нагрузки по внутренним видам. Настраивая параметры, можно разрешать как безудержный рост, так и сильное лимитирование. Данные хранятся в общей памяти и блокируются стандартными механизмами. Под такую обстановку писать — крайне удобно и просто, вопросов нет Только FSM'ы нарисовать надо, если где-то внешнее ожидание.

Примерно такой подход я и подразумевал. Причем не обязательно накладывать ограничение типа "эта задача должна исполняться в отдельном потоке" иногда хватает ограничения типа "эта задача должна исполняться на Одном и том же потоке" а это для планировщика большая разница.

N>Всё это я к тому, что "знание о том, в каком мы потоке" в Вашей терминологии почему-то приобрело дополнительное значение "в котором по счёту". Это действительно не важно, важно другое: например (простой, но понятный случай) знание и гарантия того, что нить, исполняющая какой-то код (1), не та же, что нить, исполняющая (2), независимо от того, как легли карты и что выдал генератор случайных чисел. В этом смысле "в каком мы потоке" крайне важно. Если нить A ждёт ответа на задание Y, которое отдано на вход очереди той же нити A, работы не будет. Если другой — будет.

совершенно согласен , но как я описал это ограничение намного меньше чем "задача должна крутиться в одном потоке". Просто определенный клас задач мы можем пометить как исполняемые в одном потоке. Даже больше, можно метить задачи атрибутами важности, блокирующие неблокирующие и т.п.

Система все еще отстается достаточно расширяемой.

Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:

N>>P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.

G>Не знаю как там под юниксами, но под виндами — либо, в простейшем случае, по потоку на клиента, либо IOCP. Все остальное вредно для здоровья и душевного равновесия. А то, что в юниксах такой зоопарк — разработчикам можно только посочувствовать, и пожелать скорейшего перехода на единую нормальную технологию.

Про "нормальную технологию", если уж вдаваться в эти детали — kqueue и epoll представляют собой полный аналог IOCP, особенно первый (если учесть EVFILT_AIO). Только по сравнению с Windows, у kqueue и вообще построения работы с файловыми объектами в Unix есть существенное преимущество: нет принудительного неустранимого навязывания асинхронного стиля при открытии; независимо от того, откуда и как ты получил дескриптор — ты можешь, если хочешь, работать по старинке блокирующими вызовами, можешь — через полное AIO, можешь — через общий мультиплексор типа select. В Windows такой гибкости нет.

Смутное преимущество виндовых IOCP состоит в том, что, если верить MSDN, поместить в них сообщение может каждый, а не только ядро. Но не думаю, что кому-то есть смысл делать из IOCP очередь сообщений уровня userland.

Ну а здоровье и душевное равновесие мы успешно получаем применением библиотек, которые в зависимости от возможностей платформы сами выбирают адекватное средство. С учётом того, что платформа вообще более спокойна (меньше странностей, неизвестных средств с отвратительной документацией и недокументированными особенностями), мне кажется, что моё, как программиста под Unix, душевное равновесие куда стабильнее, чем у среднего коллеги под Windows:)