Обнаружена D.o.S. для Tux-2.1.0-2

Тогда есть другой вариант: а чем они хороши в линуксе?
А Линус таки не всегда прав.

Вот прикольная ссылка:
http://www.linas.org/linux/threads-faq.html

Особенно я смеялся над разделом, где спрашивалось о различиях в реализациях потоков.
На скорую руку сляпанный дизайн подается, как самая совершенная технология.

2Havoc (*) (2001-11-08 19:20:51.0):
> Вот прикольная ссылка:
> http://www.linas.org/linux/threads-faq.html
И чем она такая "прикольная"? Очень хорошая, хотя и устаревшая, ссылка.

> На скорую руку сляпанный дизайн подается, как самая совершенная технология.
Вот оно, опять.

Еще один "убийственный" аргумент, позабытый было мной:
"Технология, использованная в Линухе для реализации ниток, плоха тем, что она проста,
поэтому она мне не нравится."

> 2maxcom: а к чему ты тогда упомянул двухпроцессорную машину? :)

к тому, что thttpd на этой машине делает apache, хотя thttpd почти не использует второй проц. Все тебе разжеввывать надо ;-)

2 Havoc

>В страшных количествах точно не стоит. Лучше необходимый минимум.


Так в том то и дело, что когда ниток _необходимый минимум_,
то практически один хрен легкие они, или нет. Нефиг, скажем,
на двухкаменной машине налепить 10000 ниток и тащиться
с того что они быстро переключаются.

>У меня куча потоков могла одновремменно исполнять один и тот же код.

Камней в машине тоже _куча_ ? Чтобы эта куча потоков
_один и тот же код_ выполняла.

bsp

2 anonymous (*) (2001-11-09 02:02:58.0): Иногда нужно (или просто удобно), чтобы N потоков исполняли один и тот же код. У меня вот в том, что я пишу сейчас, в проге с выполняются N потоков (а в потоках живут виртуальные юзеры, грузящие сервер). Машина 4-х процовая, платформа - .NET. Виртуальные юзеры написаны так, что друг другу почти не мешают (блокировки есть только когда они пишут в лог или запрашивают расшареные данные). Над ними стоит поток-супервизор, который смотрит, не подвисли ли они, а если это так, абортит потоки а запускает их по новой. Еще один поток мониторит что писАлось в логи (т.к. если в логи пишутся сплошь FAIL, значит аппликейшен сдох). Такая вот недетерминированная петрушка. Возможно будет еще один поток, который будет в логи писать. Я к нему в очередь буду добавлять что в лог писать, а уж он будет писать это все говно в логи. Добавить в очередь - гораздо более быстрая операция, чем писать в поток. Уменьшаем блокировки. Просто когда пишешь многопоточные приложения надо сначала сесть и крепко подумать. А потом, по мерере того, как implementation обретает очертания, пару раз ее переписать.

> поток-супервизор, который смотрит, не подвисли ли они, а если это так, абортит потоки а запускает

Я блин чуть не сблевал прямо на клаву от этого шедевра. Некая хрень пишется якобы для
исполнения некой работы. Этой хрени много, но она "почти" не мешает другой хрени, а над всей этой хренью
стоит главная хрень, которая в сущности и исполняет главную работу - поднимает повисшую
хрень, которая все-таки иногда мешает друг другу ;))))))) Если количество
поднятой хрени превыщает количество зависшей, то считается, что задача $M-программера
выполнена успешно. Браво! Получите деньги в кассе.

2anonymous (*) (2001-11-09 05:33:59.0): "над всей этой хренью стоит главная хрень, которая в сущности и исполняет главную работу - поднимает повисшую хрень"
Отдохни анонимус, та главная хрень называется watchdog см. http://www.linux.org.ru/jump-message.jsp?msgid=130949

2 anonymous (*) (2001-11-09 05:33:59.0): Нет, просто модули в виртуальных юзерах не всегда можно так написать, чтобы в них работал таймаут. Допустим вам нужно нагрузить некую систему не через HTTP (который таймаут поддерживает), а система эта под нагрузкой нестабильна. Модуль не реализует таймаут. Вы что виртуального юзера не будете передергивать? И сколько у вас их останется активных через 72 часа? Или это просто вам спизднуть что-нибудь хотелось?

>Еще один "убийственный" аргумент, позабытый было мной:
>"Технология, использованная в Линухе для реализации ниток, плоха
>тем, что она проста, поэтому она мне не нравится."

Там было заявлено, что в линуксе самая лучшая реализация.
Это не агитка и не маркетоидная чушь? Она действительно самая лучшая?
Лучше, чем в Solaris, AIX, True64 UNIX?. Про NT не говорим, дабы не раздражать.

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

Чисто по американски - назвать свое дерьмо самым лучшим. Но от этого оно не перестает быть дерьмом.

P.S. хочешь, линк на хоумпагу Антихриста дам? :)

Privet Havoc. Havoc (*) (2001-11-09 11:17:28.0)

Dlya nachala nugno opredelitsya dlya chego nugni nitki.

1. Esli oni nygni dlya obrabotki Userov to ideya kotoraya v Solaris, AIX, True64 UNIX, NT operacionkach kak nelza lychshe!

2. Esli dlya sistem gede v Programme zaplanirovanoe kolichestvo nitok to Ideya Linuxa ochen ne plocha .

Pervuyou mogno zavalit pri kolichestve klientov X*10000000M Ili prosto sgenerirovar "Dos" ..
Na vtoruyou Tut Kak Programmu napishesh...

A Radovatsya tomy chto gdeto nitki delayout bistro switch ne imeet smisla . Glavnoe chtob STABILNO RABOTALO.


Ps: Mne samomu ne nravitsya chto Linut nitki ne dodelanie !!!

Привет, kred.

>Pervuyou mogno zavalit pri kolichestve klientov X*10000000M Ili
>prosto sgenerirovar "Dos" ..

Не обязательно. Тут тоже, как напишешь. Делаешь пул ниток и не даешь ему разрастаться выше определенного количества.

>Na vtoruyou Tut Kak Programmu napishesh...

Ага. Ибо бесконечный fork тоже не рулез.

>Ps: Mne samomu ne nravitsya chto Linut nitki ne dodelanie !!!
Хорошо, но к сожалению некоторые воспринимают слова Линуса, как абсолютную истину :(
Да и я ж абсолютно не против, чтбы их доделали.

Ладно, какой-то консенсус достигнут и я рад, что есть мыслящие люди.
Думаю, flame исчерпан.
Всем всего хорошего.

>Виртуальные юзеры написаны так, что друг другу почти не мешают >(блокировки есть только когда они пишут в лог или запрашивают >расшареные данные). Над ними стоит поток-супервизор, который смотрит, >не подвисли ли они, а если это так, абортит потоки а запускает их по >новой. Еще один поток мониторит что писАлось в логи (т.к. если в логи >пишутся сплошь FAIL, значит аппликейшен сдох). Такая вот >недетерминированная петрушка.

Да уж, действительно петрушка... Одни пишут, отдыхают на блокировке, другой сидит, читает, отдыхает на блокировках пишущих, третии смотрит, все это с проца на проц перешвыривается. Как минимум пару-тройку из всех этих потоков можно объединить в один...
Вот тот пример, когда человеку дали молоток, а он себе по лбу стремится...

>Просто когда пишешь многопоточные приложения надо сначала сесть и >крепко подумать.

Вот-вот, подумать не вредно. Особенно когда хочешь знакомить окружающих со своей, так сказать, 'архитектурой
". Вот блин, новомодный подход к программированию -- гордиться четырехпроцессорными машинами, дот-нетами -- и надеяться, что вся эта высокотехнологичная херня скомпенсирует недостаток мозгов:(
Кстати да, я слышал много раз про 'культурные проблемы' МС-овских программеров -- любят они все переусложнять, наворачивать убийственные структуры данных, тысячи потоков там, где без этого прекрасно можно обойтись. Это у вас такая специальная политика -- чем больше потоков шефу покажешь, тем меньше шансов, что уволят?

>>Pervuyou mogno zavalit pri kolichestve klientov X*10000000M Ili
>>prosto sgenerirovar "Dos" ..
>Не обязательно. Тут тоже, как напишешь. Делаешь пул ниток и не даешь >ему разрастаться выше определенного количества.

Togda Kolichestvo Klientov budet ogranicheno... Chto v "ideale" ne est shorosho !

>>Na vtoruyou Tut Kak Programmu napishesh...
>Ага. Ибо бесконечный fork тоже не рулез.

A Tak nikakich forkov i ne nugno ! prosto est vsakie nitki kotorie sozdayoutsya pri starte... Dalshe obrabativayout NE BLOKIRUEMIE zaprosi .
Pri etom podchode do feni kakaya "model" Nitok .

Konechno pri Gui tam Linux nitki PARASHA. Obidno -;)

>>Ps: Mne samomu ne nravitsya chto Linut nitki ne dodelanie !!!
>Хорошо, но к сожалению некоторые воспринимают слова Линуса, как >абсолютную истину :(
>Havoc (*) (2001-11-09 13:00:02.0)

Ny eto ne vilechit ;) Ved slova Billa toge slushayout, chto toge obidno.

2Havoc (*) (2001-11-09 11:17:28.0):
> Там было заявлено, что в линуксе самая лучшая реализация.
> Это не агитка и не маркетоидная чушь? Она действительно самая лучшая?
Я считаю что "ДА"!
Много раз эти вопросы обсуждались при разработке 4 ядра.
Линус очень убедительно рассказал, почему он на этом настаивает.
Все разработчики согласились. Продолжают высказывать недовольство лишь
ламеры и новички.

Вкраце: в тех редких случаях, когда нитки действительно нужны,
Линуксовых вполне достаточно. С другой стороны, Линукс не предназначен
для установки на могучие сервера с полусотней процессоров. Попытка
реализации на уровне ядра ниток типа "многие-многие" типа как в Солярке
приведет к неэффективной работе на однопроцессорных машинах.

Пойми, Линус действительно придумал очень остроумный, эффективный и
простой способ реализации легких процессов (я про clone). Главное его
достоинство в том, что он не нарушает масштабируемости - система
одинаково хорошо работает и на однопроцессорном пеньке на 60 mHz, и на
восьмипроцессорном серваке на Ксеонах. На сегодня другой такой системы в
природе нет.

От того, что другие до этого не додумались, способ этот не становится
плохим. И сделано это отнюдь не "за два дня" "на скорую руку", как тебе
пытаются внушить недалекие маркетоиды.

Ты можешь сколько угодно твердить: "Линуховые нитки - отстой!", но ни
одного аргумента не ты, ни прочие критики так и не привели.

Ну блажен, кто верует и кто читать не умеет. А способ таки простой, но далеко не лучший.
А что Линус говорил про поддержу систем с большим кол-вом процов, NUMAQ, etc?
А тут ты говоришь, что не предназначен.
А еще Линус приводит аргумент против CVS, "Лично мне это не удобно".
Ура, товарищи, Линус сказал.
Да Линус - сам маркетоид, и за ламеров и новичков не выступай, на линуховых сайтах сами линуксоиды и критикуют. Интересно, ты к какой категории себя относишь? Причем критикую далеко не самые глупые. А тебе просто подумать лень. Я не услышал от тебя ни одного аргумента ЗА. В NT нитки нормально фурычат даже на одном проце.
Ты про масштабируемость _вниз_ говоришь? Может быть. Но _вверх_ такой подход не катит.
Есть два мнения, Линуса и неправильное. Я уже в этом неоднократно имел возможность убедиться. К сожалению.

До свидания.

2 kred:
>Togda Kolichestvo Klientov budet ogranicheno... Chto v "ideale" ne est shorosho !

Количество обрабатываемых клиентов всегда ограничено. Например, что делаем в апаче, для увеличения кол-ва обрабатываемых процессов: увеличиваем пул процесов. Если надо, то можно сделать чтобы пул сам разрастался и сам уменьшался, вариантов море.

>Dalshe obrabativayout NE BLOKIRUEMIE zaprosi.
Т.е. poll/select? Хороший подход, но тоже до бесконечности кол-во клиентов не подымешь.

Резюме: обычно для решения проблемы существует несколько подходов. И сразу отбрасывать все кроме одного истинно верного по словам идеологов - несколько непрофессионально. Стоит рассмотреть если не все, то хотя бы несколько. Нитки и в видах не единственное решение.
Неблокирующий IO присутствует. В общем стоит выбрать подход, а не использовать тот один, который знаешь.

2Havoc (*) (2001-11-09 17:27:43.0):
> А тебе просто подумать лень.
Ну, я про тебя хотел сказать аналогичную вещь :).

> Я не услышал от тебя ни одного аргумента ЗА.
"ЗА" что?
Ты говоришь: "В Линухе хреновые нитки."
Я прошу тебя намекнуть, чем же они хреновые. Заметь, не разжевать/
подробно разъяснить, а всего лишь привести хоть какой-нибудь заслуживающий
внимания аргумент.

Ты мне в ответ:
"Я не услышал от тебя ни одного аргумента ЗА"

Т.е. с логикой у нас напряженка ;)
Особенно мне понравилось ( в несколько вольном пересказе звучит просто
как шедевр):
Линус сказал, что лично ему не удобен CVS -> Линус - сам маркетоид ->
ни в коем случае нельзя верить его словам.

Ок, озвучу свою позицию по данному вопросу:
1. Ты что, думаешь, что Линус просто так решения принимает, не думая ни о чем?
Т.е., приходит домой, выжирает поллитру и - кидает монетку, чтобы принять
решение?

В отличие от критиков, Линус (почти) всегда подробно объясняет, почему он принимает
то или иное решение. Я много раз читал его доводы, и почти всегда он меня убеждал.

2. Какая выгода Линусу в принятии неоптимального рещения? Начальства над ним нет;
денег за это он не получает; сроки на него хотя и давят, но не в такой степени, как на
разработчиков коммерческого софта.

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

Т.о."манагеры" впаривают "начальникам" то, что они напроизводили,
а "секретарши" и "программисты" никак не пересекаются.

Соответственно, недостатки неоптимальных решений всплывают не сразу.
Ну, да и Бог с ними! Достаточно "манагеру" убедить "начальника" в том,
что решение было-таки оптимальным - "секретаршу" никто не спросит,
а "программист" сваяет все, что хошь - не ему ж на этом работать!

Так и рождаются легенды про нити, Яву, SMP и т.п. И теперь большинство
настолько привыкло к тому, что черное - это белое, что вопросы эти
даже обсуждать не принято. Не прилично!

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

3. Агрессивное неприятие позиции Линуса по моим наблюдениям имеет мест
быть у людей, не согласных с Линусом из идеологических соображений.
Как правило, такие люди не могут внятно объяснить, почему они не согласны,
но кивают при этом на авторитеты, типа "это всем известно". Просто
за последние несколко лет манагеры весьма преуспели в обработке общественного
мнения, а Линус остался человеком мыслящим. Естественно, он вызывает
раздражжжение у ламеров/легковнушаемых.

Линус сделал правильно IMHO. Он позволил нитям разбегаться по процессорам, а если тебе нужны user-space нити - берешь, понравившуюся тебе библиотеку, по той же самой приведенной тобой ссылке и пользуешь ее. Т.е. все довольны: есть оба типа нитей, в зависимости от задачи пользуешься либо тем либо другим. А запихивать обе разновидности в ядро незачем.

2 ясновидящий AC: Вот что меня всегда добивало, так это линуксоидская безапелляционность. Даже не глядя в код и не зная о чем речь, линуксоид сразу утверждает, что, цитирую, "минимум пару-тройку из всех этих потоков можно объединить в один". НЕЛЬЗЯ. Виртуальные юзеры должны работать ОДНОВРЕМЕННО, в этом их смысл. :0) Причем проблемы с блокировками невелики, т.к. 99.999% времени выполнения виртуальные юзеры варятся в собственном соку, а когда нужно что-то в лог писать, то блокировка делается лишь на время перекидывания ссылки на строку (а они в .NET иммутабельны) в очередь. Так что запускаем мы тут per instance 50+2 потока, плюс несколько instances на машину. Плюс все это на 8 машинах работает. Нам ведь 1500 concurrent users надо сэмулировать. И чтоб реалистично было. А вы, батенька AC, оказывается, баран. И кругозор у вас бараний. Мои соболезнования.

2 Bluezman: Ну, во-первых я не линуксоид. Во-вторых, лично ваша безапеляционность меня всегда неприятно удивляла. Во-третьих, чтобы догадаться, что можно объединить, не нужно смотреть в код, а ваша задача ясна как божий день -- сэмулировать нагрузку на систему массового обслуживания. Наконец, о каких потоках идет речь -- во-первых, выкинуть запись в лог из юзеров -- первое очевидное решение, странно что вы рассматриваете его как возможное. Во-вторых, поток, который лазит в лог на предмет FAIL, FAIL, FAIL... и определения смерти приложения -- тоже не нужен, он только создает лишнюю "блокировочную нагрузку". Эту работу можно делать в том же потоке, который пишет из очереди в лог -- если он хавает из очереди сплошные FAIL, следовательно, умерли. В-третьих, если подумать, то в принципе watchdog и logger можно совместить, если вести в логгере статистику частоты обращения от потока -- если их мало по сравнению с сообщениями от других потоков, то он сдох. Хотя в последнем я не уверен. Тут, как вы выразились, подумать надо. Заодно, хотелось бы посоветовать вам подумать над вашим хамством. А то, пользуясь вашей сельскохозяйственной терминологией, быкуете много. Мои соболезнования.

2 АС: А тот поток не лазит в лог. Это слишком тупое и прямолинейное решение, если вы так круты, то в общем-то непонятно, как вам такое пришло в голову. Дело в том, что момент, когда юзер пишет в очередь недетерминирован. Мало того, то, на что создается нагрузка работает на кластере, и нестабильна может быть лишь какая-то часть приложения, а не все оно целиком. Анализировать записи в очереди означало бы длительные блокировки при записи из VUser'а. Я делаю следующим образом (точнее планирую сделать, пока руки не доходят) - перекидываю записи (а запись через каждые N где n примерно равно 10000 добавлений в очередь происходит) из очереди логгера в другой поток, а он уже там разбирается, висит или не висит, никого не блокируя, а если обнаружил, что висит - делает шатдаун на нагрузку конкретного куска приложения. Выкинуть запись в лог из юзеров тоже нельзя, т.к. собирается информация о performance характеристиках системы, latencies, и прочее. Тем более, что сами юзеры в лог не пишут. Они пишут в in memory очередь, обрабатывает которую отдельный поток. Далее, третья часть. Логгер и ватчдог совместить нельзя, т.к. одни действия в виртуальных юзерах длятся 60 миллисекунд (через оптоволокно), а другие - в которых шагов побольше - до 15 секунд. И порядок выполнения действий псевдослучаен. И чем больше действий, тем более случаен порядок их выполнения. Можно настраивать только приоритеты, с которыми будут выполняться действия (не путать с приоритетами потоков). Так что по всем трем пунктам - мимо тазика.

А что касается хамства, то хамить, уважаемый, первым начали вы. Так что неча на зеркало пенять.

>А тот поток не лазит в лог. Это слишком тупое и прямолинейное >решение, если вы так круты, то в общем-то непонятно, как вам такое >пришло в голову.

Могу процитировать, если желаете. "Еще один поток мониторит что писАлось в логи (т.к. если в логи пишутся сплошь FAIL, значит аппликейшен сдох)." Твои слова, Каифа:)

>Анализировать записи в очереди означало бы длительные блокировки при >записи из VUser'а.

Это зависит от сложности анализа. Если он простой (типа проверить, FAIL или нет), то анализировать запись (в логгере) можно сразу после того, как ее сняли из очереди. Никаких длительных блокировок.

>более, что сами юзеры в лог не пишут. Они пишут в in memory очередь, >обрабатывает которую отдельный поток.

Который, надо надеяться, и есть логгер?

>Логгер и ватчдог совместить нельзя, т.к. одни действия в виртуальных >юзерах длятся 60 миллисекунд (через оптоволокно)

Для начала, ватчдог -- это поток, который анализирует, жив ли пользователь, и убивает дохлых? Тогда совмещение зависит от того, сбрасывает пользователь информацию в лог один раз, или делает это на протяжении всей жизни, и если да, то совпадает для всех пользователей среднее ожидаемое количество операций. Если да, то в процессе получения записей в логгере можно строить гистограмку, после N записей брать потоки, которые писали меньшее число раз, чем заданный (или динамичный) threshold, или как то еще ее анализировать, и отдавать номера таких потоков одному по жизни _спящему_, чтобы он их прибил и создал новые, чтобы не тратить время на операции с пулом потоков и всю эту лабуду в логгере-ватчдоче. И, в итоге, от времени и порядка выполнения операций ничего и не зависит. Конечно, такое решение оправдано только в том случае, если пользователи дохнут относительно редко. Так по поводу совмещения, я и говорил, что, так сказать, с'est discutable...

> что касается хамства, то хамить, уважаемый, первым начали вы.

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

P.S.: И что, в дот-нете действительно иммутабельные строки, как в жабе? Т.е, копируются при изменении? И тоже есть какой-ндь StringBuffer для быстрых операций по изменению строки, и объекты строки/буфера надо регулярно друг в друга конвертить? Если так, то можно сказать только одно -- мля:( Надо ждать "dot net perfomance tips"?

Ну и что вы процитировали? По вашему для того, чтобы посмотреть, что писалось в логи нужно обязательно читать файлы?

Хе, а кто вам сказал, что ватчдог все время бодрствует? Это не так. Да, юзеры пишут все время своей жизни. Причем делают это пачками, чтоб надолго не блокировать, т.к. пишут много. Пока в каждом модуле до 10 измерений + суммарное время транзакции (это излишество, можно было бы считать потом, но так было изначально, а убирать лень) + резултьтат (pass, fail, no run). Они ведь у меня между шагами спят псевдослучайное кол-во миллисекунд. Среднее ожидаемое кол-во операций мне даже не известно. Либу писал я (на C#), а модули пишут уже тестеры (на VB.NET, им так проще).

Для строк в .net есть StringBuilder.

А перформанс там всегда будет выше чем в жабе, т.к. выполняется native code.

Теперь что касается того, как началась дискуссия. Мне вас очень жаль, если вы считаете, что я имел целью кого-то опустить и что вы тот постинг, видимо, восприняли на свой счет. Я всего лишь поделился примером РАБОТАЮЩЕГО приложения, где без нормально реализованных тредов пришлось бы поиметь на порядок больше геморроя. Вы же начали хамить и наезжать на MS почему-то, и на программеров, которые там работают (cream of the crop, by the way).

>Для строк в .net есть StringBuilder.

И операция +, как в жабе, которая копирует? Тогда, как и в жабе, никто этим билдером пользоваться и не будет, а будут, как обычно, делать все через +. Короче, позаимствовали чуть ли не самое мерзкое решение из жабы?

>А перформанс там всегда будет выше чем в жабе, т.к. выполняется native code.

Какая разница, нативно или нет в цикле каждый раз выполняется создание строки и ее копирование? Что нативно, что нет все равно будет тормозить...

>всего лишь поделился примером РАБОТАЮЩЕГО приложения, где без нормально реализованных тредов пришлось бы поиметь на порядок больше геморроя.

Да ну. Ну были бы "тяжелые" нитки, чтобы изменилось?

AC> Да ну. Ну были бы "тяжелые" нитки, чтобы изменилось?
На это блузману ответить нечего - значит действительно пытался здесь всех опустить. Программер, мля.

2anonymous (*) (2001-11-11 12:37:41.0): ежу понятно чтоб было с тяжелыми нитками - масштабировалось бы хреново...

2 Irsi: А хрен ли линуксоидам. Они рассуждают так, как будто у них ресурсы не ограничены. Ну понадобится в полтора раза больше машин, ну и что? Красноглазым студентам компьютеры покупают родители. А у меня в лаборатории 3 deployment scenario и фиксированное количество клиентских машин. А не пишу потому как ЖАРКО становится. Вот щас воскресенье, 2.44 утра, а я еще работаю. :0) Модуль дрючит сервер на работе пока. У меня перекур.

2 Irsi: Когда о чем-то говоришь, нужно для начала "определиться с терминологией". Что значит "легкие" нитки, что значит "тяжелые"? Что значит "нормально реализованные"? Как в NT, с "меньшим" контекстом?
Почему такая реализация должна считаться эталонной? Еще раз повторю, я не линуксоид, мне просто не нравятся необоснованные гоны. Вы сравнивали затраты времени хотя бы на переключение контекстов в том же Linux и NT? И кроме того, повторюсь -- когда наличествует большое число одновременно выполняющихся легких/тяжелых нитей/процессов (как в задаче у Bluezman'a), затраты на их синхронизацию намного превышают затраты на переключение контекстов. Поэтому тут от величины контекста ничего не зависит.

2 Bluezman: И как всегда, без оскорбления окружающих обойтись нельзя? Или, может быть, вы считаете, что только вы один работаете? И только у вас есть лимиты на ресурсы? Да и в конце концов, что такого плохого быть "красноглазым" студентом/аспирантом? По крайней мере, IT вперед двигаем мы, а не вы -- жалкие "практические" инженеришки, которые только пользуются плодами чужого труда.

Масштабировалось бы хреново - это одно. Но у него спросили, как бы изменилась архитектура его приложения, если бы он имел дело с тяжелыми нитями. Ведь он сказал:
"Я всего лишь поделился примером РАБОТАЮЩЕГО приложения, где без нормально реализованных тредов пришлось бы поиметь на порядок больше геморроя." Вот на это ему ответить нечего, судя по тому, что он говорит о чем угодно (ресурсы etc.), но не отвечает на этот вопрос.

P.S. Кто не понял: "он" - это всеми любимый блюзман.

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

Не думаю что стоит наезжать на прикладных программистов. Если на то пошлО, то конечный результат, от которого людям жить веселее, создают именно прикладные программисты.
Кроме того, IT двигают вперёд во многом и в основном манагеры больших контор, а никак не аспиранты и не программисты. Двигают за счёт того, что разводят остальные отрасли на бабки, часть которых как раз идёт на прокорм студентов/аспирантов.

Так шта, пока не докажешь, что я пользуюсь твоим(?) трудом, твоё заявление - пустой трёп.

>Не думаю что стоит наезжать на прикладных программистов.

Это только в ответ на идиотские вопли о 'красноглазых, которым родители компы покупают'. Что, в значительной мере является упрощением ситуации. Ну в общем, какова исходная посылка, таков и ответ.

>Если на то пошлО, то конечный результат, от которого людям жить >веселее, создают именно прикладные программисты.

Пользуясь при этом идеями и технологиями, созданными теоретиками.

>Двигают за счёт того, что разводят остальные отрасли на бабки, часть >которых как раз идёт на прокорм студентов/аспирантов.

Сами по себе бабки не дают идей, очевидно.

>Так шта, пока не докажешь, что я пользуюсь твоим(?) трудом.

Если у вас есть сомнения, что IT делают не в университетах/research centers (пусть даже принадлежаих всяким конторам), то no comments... Кроме того, что, это может быть вы сами придумали многозадачность, unix, OOP, базы данных, интернет в конце концов? Так что, по любому вы пользуетесь плодами чужого труда. Понятно, что стипендия у аспиранта даже здесь меньше, чем у 'практического программиста' business applications. Только потом эти аспиранты или в процессе своей работы, или потом в research centers создают то, чем пользуется все остальные.

>твоё заявление - пустой трёп.

Конечно, пустой треп. Оно было вызвано идиотской исходной посылкой. Ещё не хватало на полном серьезе обсуждать, что первее -- яйцо или курица.

2 AC: Ну и много таких аспирантов (тут кстати аспирантов нет, а что создали российские "теоретики" в компьютерной области - для меня загадка, и не только для меня), которые создают то, чем пользуются другие? Уж лучше прикладным программистом в каком-нибудь Windows division работать. Вот уж чем пользуются все кому не лень и кому идеология не мешает. Опять же деньги зарабатываются на гранты "теоретикам" из MS Research и не только. И понимаете ли в чем дело, то что ты чем-то занят, здесь ничего не значит. Чего-то значит если ты чего-то достиг (продукт довел до релиза, написал тулзу, которая сэкономила твоей команде время и деньги etc). А рассуждать о том, как сделать лучше, я и сам горазд. Только дъявол - он в деталях. А потому никогда не беритесь рассуждать о чем-либо, не зная деталей, теоретик вы наш.

А bluesman'у действительно нечего ответить про геморойные изменения в архитектуре приложения. Ну привел он пример рабочего приложения - молодец, возьми с полки пирожок.

2 dik: мне не нужны user space нитки. Кооперативная многозадачность меня не очень привлекает.

2 anonymous:

Я всего лишь привел пример обоснований Линуса. Он принимает решения удобные ЕМУ ЛИЧНО.
А недостатков тебе уже называли. Тяжелость. Этого хватит.
Да, с этим можно бороться, но факт остается фактом.
Если ты скажешь, что все равно будут куча блокировок, то я тебе отвечу, что совсем не обязательно.
Если ты будешь форкаться и обмениваться данными между потомками, то с блокировками тебе тоже придется столкнуться.

Ты еще скажи, что на www.fbi.gov апач стоит.

P.S. Ты вообще кто? Программист? Админ?
Если программист, какие задачи решаешь?

>тут кстати аспирантов нет

Здрасьте, нет... А я тогда кто????:)

>Если ты скажешь, что все равно будут куча блокировок, то я тебе отвечу, >что совсем не обязательно.

Это почти всегда обязательно. Особенно если много однотипных потоков.

>Если ты будешь форкаться и обмениваться данными между потомками, то с >блокировками тебе тоже придется столкнуться.

Дело не в том, что если fork'ться, то блокировок не будет. Дело в том, что fork'аться или CreateThread'иться -- все равно, если вероятность блокировок высока, поскольку все равно большинство затрат будет вызвано не переключением контекста.

2AC: эээ... давайте начнем тогда уж с того что далеко не все алгоритмы/задачи нормально распаралеливаются?

> давайте начнем тогда уж с того что далеко не все алгоритмы/задачи нормально
> распаралеливаются?

Все-таки, Irsi - умный! Если б еще не такой доверчивый был...

Беда в том, что подавляющее большинство задач вообще не поддаются распараллеливанию.
Че в Ворде параллелить?

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

Это что касаемо реальных задач.

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

А почему именно fork?
Потому как отцы и деды его использовали?

А почему именно форком?
Потому что отцы и деды так делали?

> А почему именно форком?
А что, можно как-то иначе?

Ну да, в Виновсе, типа, можно самого себя с диска загрузить.
Дык, это ж Доса еще. Дос-то однозадачным был, поэтому там форка
не надо было, вполне екзеком обходились. Так с тех пор у мастдайщиков
нелюбовь к форку...

Дык, просвети, как без форка форкнуться? Т.е. сделать второй такой же процесс,
независимый от первого?

>Дык, просвети, как без форка форкнуться? Т.е. сделать второй такой же процесс, независимый от первого?

Ну как же? Есть же единственный, неповторимый и единственно правильный способ: CreateProcess :) Стыдно такого не знать...:)

>Дык, просвети, как без форка форкнуться? Т.е. сделать второй такой
>же процесс, независимый от первого?

Если независимый, то да, fork логичен, а если ситуация противоположная?
Тут уже несколько сложнее.
Да и не о виндовсе конкретно речь, чуть что, сразу на виндовс съесжают.

Т.е. например в каком либо офисе для работы фонового чекспеллера fork, имхо, нафиг не нужен.

2AC (*) (2001-11-12 19:25:07.0):
> Ну как же? Есть же единственный, неповторимый и единственно правильный способ:
> CreateProcess :)
Дык, и я об чем?

Compare:
> Ну да, в Виновсе, типа, можно самого себя с диска загрузить.

> The CreateProcess function creates a new process and its primary thread. The new
> process executes the specified executable file.
Все дружно вспоминаем ДОС!

Конечно, тут технология КРАЙНЕ передовая:
Зачем нам форк? Отсталая технология! Заместо скрестим автоподъем с диска с
супер-пупер нитками!

Знаете, Нтя мне чем-то запорожец напоминает. Тоже КРАЙНЕ прогрессивные технологии
были наворочены...

2Havoc (*) (2001-11-13 12:12:07.0):
> Если независимый, то да, fork логичен, а если ситуация противоположная?
...
> Т.е. например в каком либо офисе для работы фонового чекспеллера fork, имхо,
> нафиг не нужен.
Не въехал...
Делаешь форк, затем екзек. В чем проблемы?
Не хочешь дату копировать -- делай vfork. Получишь выигрыш аж в миллисекунду!
Очень критично для "фонового чекспеллера" :0)

А вот CreateProcess - типичная лишняя сущность, какие столь любы M$.

> Да и не о виндовсе конкретно речь, чуть что, сразу на виндовс съесжают.
Ну, извини, коли задел ;)
Просто для "виндовс" характерно выдывать допотопные технологии за немыслимый
прогресс, а всякие ... некритично мыслящие индивидуумы на эту удочку
попадаются...

2Havoc (*) (2001-11-12 14:19:35.0):
> Ты вообще кто? Программист? Админ?
> Если программист, какие задачи решаешь?

Наверное, ко мне вопрос - извини, что не подписался. Не думал,
что дискуссия получится, а подпишешься - так из флейма потом не
вылезешь :)

С последней странички:
anonymous (*) (2001-11-08 20:01:02.0)
anonymous (*) (2001-11-09 15:47:43.0)
anonymous (*) (2001-11-09 18:35:51.0)
anonymous (*) (2001-11-12 17:15:31.0)
anonymous (*) (2001-11-12 18:28:29.0)
anonymous (*) (2001-11-13 21:54:49.0)

Короче, зарегистрировался, все ж. Давно к этому шло :(

Обо меня лучше всего думать как о программисте ОЧЕНЬ широкого профиля,
наверное. Скажем так, я занимаюсь разработкой и поддержкой (того, что
я сам и разработал) софта для научных рассчетов, numeric/(G)UI/API.
Вообше-то, изначально я не программистом был, но уже лет 5 как времени
на науку почти не остается: в нашей коллаборации (не маленькой, надо
сказать), я - единственный программист (широкого профиля) получился.
Платформы - самые разные (Солярка, Альфы, IRIX, HP), а десктоп у меня,
ессно, Линукс - когда я начинал, Фри еще не было.

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

Последние годы крепко засел в в Забугории. Пока назад не собираюсь,
хотя и тут пока никакого гражданского статуса нет.

Знаешь, если подробнее напишу, придется регистрацию менять - уж больно
вычислимо все. Тебе, наверное, интересно всего лишь про мой опыт
распараллеливания.

Есть, но небольшой. Раньше (неск. лет назад) я, нанюхавшись нитей/SMP,
тоже бросился все это изучать. Постепенно понял, что все это - глупость.

Больше всего меня потрясло, когда оказалось, что для моих супер-параллельных
задач не было разницы в производительности fork() vs. system()...

Про SMP вообще молчу - пообщавшись со спецами, понял, что мне таких задач
пока не встречалось.

2Havoc (*) (2001-11-12 14:19:35.0)
> Если ты будешь форкаться и обмениваться данными между потомками, то с блокировками тебе
> тоже придется столкнуться.
Только блокировки эти будут контролируемыми - я расшарю память и
посажу блокировки на семафоры. Уверяю, никаких проблем не будет - главное, не позволять
железяке принимать решения за тебя...

>Только блокировки эти будут контролируемыми - я расшарю память и
>посажу блокировки на семафоры. Уверяю, никаких проблем не будет -
>главное, не позволять железяке принимать решения за тебя...

Дык, кто ж тебе с нитками мешает блокировки контролировать?

2 anonymous:
> А вот CreateProcess - типичная лишняя сущность, какие столь любы M$.

Ок, как ты по другому программу запустишь? Совсем не обязательно копию себя.

>Не хочешь дату копировать -- делай vfork. Получишь выигрыш аж в миллисекунду!

А copy on write? Предложишь память шарить? А зачем?
Я не подразумевал вызов ispell. Да и с внешней прогой придется хитрым образом договариваться, если она еще согласится.
Допустим спеллер у тебя встроенный, как в SO например.
И не путай спеллинг однократный и фоновый, который работает, пока ты текcт вбиваешь. Или ты предлагаешь после ввода одного слова заново форкаться? Старая собака новым фокусам учиться не желает (которые на самом деле далеко не новы)?

> Ок, как ты по другому программу запустишь? Совсем не обязательно копию себя.
(v)fork + exec.
Немного подумав, поймешь, что иначе и не получится.
Можешь, конечно, придумать обертку к этой парочке, назвать ее CreateProcess,
выкинуть fork, забыть о наследовании процессов ...

Знаешь, наш спор все больше напоминает диалог слепого с глухим :)