Переход приложений на kernel 2.6 и NPTL

>> А как при использовании fork() передать файловый дескриптор от родителя чилду и наоборот?

>Ну, если только этим задача и занимается -- таки да, это аргумент. Но эсли она ещё и чего-нить полезное делает -- надобно учесть и глюки из-за общей памяти...

ну так я поэтому и написал, что использовать нужно осторожно, я для этого дела clone() использовал только с расшаренными FD. А общие куски памяти через shared memory :)

>> как при использовании fork() передать файловый дескриптор от родителя чилду и наоборот?

>Хм, а зачем передавать от родителя чайлду, если чайлд с рождения их имеет? ;)

я ж написал, что дескриптор был создан после fork()

>man fork

типа умный, да? ;)

> Переписать вызовы libc? >Ага. Если ты думаешь, что это дикость, то разуй глаза. Серьёзные программы так и делают.

rename - вызов к ядру. Перепишите!

Ура! Каждой программе по своей libc! Где-то я это уже видел. О! www.borland.com! у ней свой правильный RTL. Чтобы чужих глюков не было, свои только. А Kylix видели? К белому другу на прощание пе потянуло?

Серьёзные программы, блин! Ёжики плакали... А потом сидишь перед залипшей GUI программой и думаешь, то ли сдохло, то ли по сети куда идёт... мы ж нити не любим...

PS. Apache версии 2 перешёл на нитки. Или я не прав? Хотя ну их, эти ламеры не знают про fsm и гениев с ЛОР :-)

Поделись программой create-pt, пожалуйста. Сам не в состоянии написать такую :-)

Отправь на opens@hot.ee

> И по скорости создания, и по скорости переключения между своими "лёгкими" процессами делает любой "родной" шедулер OS.

Вообще, чисто пользовательское решение всегда быстрее "ядерного". До тех пор, пока на машине только один проц.

> PS. Apache версии 2 перешёл на нитки. Или я не прав? Хотя ну их, эти ламеры не знают про fsm и гениев с ЛОР :-)

Тут был разговор про некий абстрактный многотредовый проект. Как ты думаешь, о чем шла речь?

Какая дичь! Неиспользование libc означает работу напрямую с syscalls, что, в свою очередь, означает либо заточку под конкретное ядро (иногда - с точностью до последнего знака версии и набора патчей!), либо просто создание своей libc (ну или kernel abstraction layer), поддержку ее переносимости, индивидуальный набор глюков, багов, дыр в секурити и пр. И кто же такой "серьезный" "так и делает"?

> Вообще, чисто пользовательское решение всегда быстрее "ядерного". До тех пор, пока на машине только один проц.

Посадить по ноде на каждый процессор. А между нодами ерланговские процессы мигрируют свободно.

А-а! Таки смешанное решение, не чисто пользовательское!:)

> Какая дичь! Неиспользование libc означает работу напрямую с syscalls

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

> Посадить по ноде на каждый процессор. А между нодами ерланговские процессы мигрируют свободно.

Если не секрет, с помощью какой функции?

> И кто же такой "серьезный" "так и делает"?

Вот кстати Erlang/OTP так и делает. Резолвер там на эрланге написан.

>Удивительно прям, что такие предположения возникают. Как уже было >сказано, в одном процессе юзаем машину состояний и неблокируемый >ввод-вывод (асинхронный).

Удивительно это только для тех, кто думает, что у всех возникают одни и те же задачи. Вот тебе вводная: application server, общающийся с ораклом. Application server - 4 процессора, Оракл - 12 процессоров. 1. AS из одного потока не сможет использовать многопроцессорность машины, на которой запущен AS. 2. В OCI есть неблокируемые вызовы, но после такого вызова нельзя использовать другие OCI вызовы. Толку от такой неблокируемости немного. Вывод - при однопоточном AS в данный момент будет выполняться только один запрос к Ораклу, что в большинстве случаев приведет к использованию только одного процессора на Оракле. Задача и набор оборудования довольно типичны для средней телекоммуникационной конторы. И если к решению этой задачи допустить людей, которые "Удивляются прям, что такие предположения возникают", то из 16 процессоров будут использоваться только 2. Предлагающим не использовать Оракл, а использовать что нибудь другое с реально неблокируемыми вызовами - встречное предложение пойти в сад.

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

Описка по Фрейду (желаемое за действительное) не мигрируют, а взаимодействуют.

это вообще получается имитация деятельности ос

для таких как вы я тут слово новое придумал (вроде еще никто не употреблял :) так вот вы - дистрофаны! :)

клиент-серверные приложения промышленного качества на питоне? вы манов обкурились :)

Основная проблема при сравнении быстродействия программ на, например, Perl и C заключается в том, что одни и теже алгоритмы ДОЛЖНЫ быть реализованы разными методами для каждого из этих языков. В подавляющем большинстве случаев Perl работает практически не медленнее чем C.

>> Гораздо более архиважным делом является переход с Java 1.4.2 на Java 1.5.

>И скока по этому поводу нада прикупить памяти ???

пока сколько влезит на мать:)

GHhost

возможно. что полностью нивелируется убогим синтаксисом перла. разуйте глаза. он же делался для анализа логов

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

Убогим в сравнении с чем?

Эээ, ты не прав. Убогий синтаксис перла даже для анализа логов плохо
подходит. Для логов идеально использовать awk.

Люди! вы случаем не ошиблись адресом? Посмотрите хоть на заголовок!

>Вот как раз потоки (ни новые ни старые) не должны никого 
>волновать. Люди, кторым нужны потоки, - недостойные, не 
>могущие построить fsm. В следующем своем воплощении они 
>будут пачкой макарон.
а те кто используют только процессы будут в следующем своем
воплощении кем? нарезным батоном?

> а те кто используют только процессы будут в следующем своем воплощении кем? нарезным батоном?

у них следующего воплощения не будет.

> Убогий синтаксис перла даже для анализа логов плохо подходит.

> Для логов идеально использовать awk.

Что называется: найдите десять отличий.

>Удивительно это только для тех, кто думает, что у всех возникают одни и те же задачи.

Согласен. Задачу надо бы уточнить, я предполагал использование однопроцессорной системы.

Соотвественно при наличии многопроцессорной системы имеем задачу распараллеливания вычислений. Процессы или потоки в данном случае просто распределяются ядром по разным процессорам. Что вполне юзабельно. Но опять же, у такой архитектуры есть проблемы как раз на больших объемах, о чем собственно kernel-девелоперы упоминали (общая память для всех процессоров). NUMA ведь не просто так появилась в ядре? Таким образом, если посмотреть чуть дальше существующих решений станет ясно, что по-хорошему от ядра требуется user-space api для NUMA, а от компиляторов умение воспользоваться этим api, для автоматического распараллеливания обычных последовательных программ. Для этого в ядре также потребуется синхронизатор кусков одной программы между процессорами. В общем, если такое организовать, то то тут будет просто рай для функциональных компиляторов, они и сейчас думаю произвольный inline могут, надо будет тока NUMA или её аналог прикрутить. Самое главное здесь, что куски будут склеиваться в той же последовательности, в какой они и были и дополнительная синхронизация просто не нужна, как например с тредами. Давайте, убедите меня, что в real-time выстраивать треды в очередь для записи общей переменной будет эффективнее, чем использование статической последовательности операций(предварительно выстороенной).

>И если к решению этой задачи допустить людей, которые "Удивляются прям, что такие предположения возникают", то из 16 процессоров будут использоваться только 2. Предлагающим не использовать Оракл, а использовать что нибудь другое с реально неблокируемыми вызовами - встречное предложение пойти в сад.

А я реально лучше б в дивный сад за цветами сходил, чем Oracle на процессорах гонять. Если мне что-то надо, чего ещё community не сообразила, я пишу сам, в том числе и gethostbyname, тока из этого асинхронный резольвер получился, причем шустрый и эффективный, да и не велосипед вовсе, так как не на C.

P.S. Интересно, это только у меня так или у всех: смотрю на программу на языке С, а вижу то ASM, то машинный код :).

Вот ещё на тему замены libc на более правильный код. Скомпилил
два экземпляра create-pt2 c libc и с dietlibc. Сама прога create-pt2
написана по-идиотски, но вот, что можно из неё выжать, используя правильную библиотеку:

$./create-pt2 -p 16
create-pt2: -p 19997 16.004 Seconds -- 1249.537 processes/sec

$./create-pt2-diet -p 16
create-pt2-diet: -p 117652 16.009 Seconds -- 7349.129 processes/sec

Почти в шесть раз увеличивается производительность!

Вот как раз синтаксис Perl - это его блеск и нищета. Хотя соглашусь, что он изначально не задумывался как язык программирования общего назначения.