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

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

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

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

Origin-J (java atop forth) рулит

А я уже gentoo собрал на основе kernel 2.6.4 + NPTL... Осталось затестировать.

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

Да как раз твой переход не волнует никого.

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

> Origin-J (java atop forth) рулит

Скорость исполнения сравнима со скоростью дрейфа материков? Или уже приближается к скорости роста травы?

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

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

А что ты предлагаешь? Юзать fork() ?? Так вообще то это не всегда оправдано, представь тебе надо обработать запрос, обработка которого занимает времени МЕНЬШЕ чем создание форка , вот здесь то и надо поток. Или ты очередной любитель жабы, которая жутко тормозная и ресурсо емкая?

Так вот такое Г как жаба умрет как класс вместе с C#, C это всегда останеться.

Опа, а авторы не менее интересны!
Peter Dibble - ко всему прочему также основоположник, разработчик (уже бывший) и главный идеолог системы реального времени OS-9 (не путать с маками). Я думал, что он до сих пор в MicroWare трудится (в позапрошлом году поглощена RadiSys), так было 2-3 года назад.

> А что ты предлагаешь?

man select

> Юзать fork() ?? Так вообще то это не всегда оправдано, представь тебе надо обработать запрос, обработка которого занимает времени МЕНЬШЕ чем создание форка ,

"Юзать" пул форков.

> вот здесь то и надо поток.

Поток не надо. Нигде.

> Или ты очередной любитель жабы, которая жутко тормозная и ресурсо емкая?

Про тормоза - это еще вопрос.

м-да... таких "идеологов" надо...

редкостная дрянь эта OS9/9000

Говорят, Java работат шустрее с ядром+NPTL. Те, кто не читал статью, заявляю, что NPTL - это следующий стандарт linux kernel.

если OS9 "система реального времени" то я Жора Буш, самый что ни на есть ;-)))

Не стандарт, а стратегическое направление для линукса в будущем.

>man select

и что? "The functions select and pselect wait for a number of file descriptors to change status." - то есть - "Ф-ции select и pselect ожидают количества файловых дескрипторов чтобы сменить статус" - это Я вольно перевел. Далее , сам думай, как прикручивать и ид и тп.

>"Юзать" пул форков.

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

>Про тормоза - это еще вопрос.

Не надо глупить, жаба как и всячиские perl etc, тормоза, сам подумай =)

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

Вообще-то это кто-то из Столпов сказал (не помню только кто), так что хорошо бы копирайты поставить... ;). Насчет вермишели спорить не буду, но про fsm я уже где-то читал.

глупишь ты, глянь сюда:

http://hoschek.home.cern.ch/hoschek/colt/index.htm

> "Ф-ции select и pselect ожидают количества файловых дескрипторов чтобы сменить статус"

Однако... (оффтопик: а как это будет по-фински?)

> не надо глупить, жаба как и всячиские perl etc, тормоза, сам подумай =)

Читать про JIT. Заглянуть на http://www.bagley.org/~doug/shootout/

offtopic \ так а посмотри что там написано - "The shootout has not been updated since the fall of 2001, and is now frozen as it is. I'm sorry, but no updates will be made.", то есть забили. собственно следующая фраза тоже не внушает доверия особенно тот момент, что никогда не закончим и будут всегда ошибки ... Вообщем все ясно.

end_offtopic

Далее там тесты приведены (сслылка во втором предложении "heer"), по которым ОЧЕВИДНО что жаба то тормоза, Я понимаю что можно себе сделать хорошую машину и каждый месяц покупать память и прочее, но извините это как и у винды m$-ой получиться.

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

fsm на select - это портабельно, канеш, но меня лично коробит
а) FD_SETSIZE (1024 на 2.4, кажется)
б) пробежки по set'у в поисках сокета, изменившего состояние

А вот непортабельно и красиво - это kqueue, но иво на линуксе нету ;)

//Losiki

PS а ты, альфекс, книшки четай. Они рулиз, какизвесна.

>А что ты предлагаешь? Юзать fork() ?? Так вообще то это не всегда оправдано, представь тебе надо обработать запрос, обработка которого занимает времени МЕНЬШЕ чем создание форка , вот здесь то и надо поток. Или ты очередной любитель жабы, которая жутко тормозная и ресурсо емкая?

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

Я не пойму, что вы привязались к этому fsm. Ведь кроме сервер/клинтских приложений есть еще куча приложений которым нужны потоки. Например любая игра: один поток на графику, другой на физику, третий на ввод, четвертый на звук, пятый на сеть и тд. Если это делать fork'ом, то получится все-таки медленние чем на нитях.

p.s.
Кстати я у себя замерял, скорость создания процессов и потоков. Так вот, разницу в процентах измерять не удобно, лучше в порядках. Впрочем цифры сами лучше все покажут:

root@duron other # ./creare-pt -p 5
creare-pt: -p 1304 5.001 Seconds -- 260.739 processes/sec
root@duron other # ./creare-pt 5
creare-pt: 804952 5.001 Seconds -- 160961.363 threads/sec

Я забыл сказать, что эти результаты получены на Linux 2.6 + NPTL, с LinuxThreads результаты были убогие.

> Если это делать fork'ом, то получится все-таки медленние чем на нитях.

Синхронизация у тебя бесплатная? Назови систему, ха-а-ачу такую.

> Кстати я у себя замерял, скорость создания процессов и потоков.

Про префоркед пул кому говорили? Скорость _создания_ никого не интересует.

Покажи насколько убогие, мне интересно!

> Про префоркед пул кому говорили? Скорость _создания_ никого не интересует.
Уху. И обьем памяти занимаемый этим пулом тоже никого не интересует...

> Уху. И обьем памяти занимаемый этим пулом тоже никого не интересует...

Тех, кто не слышал про COW интересует.

А не объяснит ли благородный защитник абсолютно не перерасходующих память тредов, почему авторы многотредных программ (не будем их - программы - пока называть) рекомендуют периодически прибивать их чудесные программы? Наверное из-за того, что те умеют отдавать память, отожранную под стек?

>А я уже gentoo собрал на основе kernel 2.6.4 + NPTL... Осталось затестировать.

А я уже в продакшин поставил сервер с 2.6.4 + NPTL на дебиане, и ничего собирать не надо было.

> А не объяснит ли благородный защитник абсолютно не перерасходующих память тредов, почему авторы многотредных программ (не будем их - программы - пока называть) рекомендуют периодически прибивать их чудесные программы? Наверное из-за того, что те умеют отдавать память, отожранную под стек?

Я наверное зря ввязался в этот спор, так как не являюсь особым проффесионалом в этой области, но я все же попробую :). По-моему, то что вы сказали это исключительно проблема этих самых программ и программистов которые эти программы разрабатывают. pthread_join должен убивать все, что осталось от треда.

> Покажи насколько убогие, мне интересно!

2.4.22-openmosix + LinuxThreads :
creare-pt: -p 1332 5.006 Seconds -- 266.057 processes/sec
creare-pt: 74863 5.002 Seconds -- 14966.814 threads/sec

>Я не пойму, что вы привязались к этому fsm. А почему бы и нет? Полный контроль над процессом и эффективность как никак.

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

Можно задачу планировки отдать ядру, а можно использовать свой планировщик, который необходим для данного типа приложения. Так что любую программу на тредах можно реализовать и без них, причем более качественно. Следовательно гораздо важнее развивать мультиплексные engine,API в целом, чем частный kernel-случай.

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

> По-моему, то что вы сказали это исключительно проблема этих самых программ и программистов которые эти программы разрабатывают. pthread_join должен убивать все, что осталось от треда.

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

> creare-pt: -p 1332 5.006 Seconds -- 266.057 processes/sec

> creare-pt: 74863 5.002 Seconds -- 14966.814 threads/sec

Впечатляет. Но цена создания - никому не интересна.

А я так вообще не знаю, что такое Java... Видимо очень важная весчь ;)

А как при использовании fork() передать файловый дескриптор от родителя чилду и наоборот? При этом если дескриптор был открыт уже после fork().
На тредах это без проблем.
И это только то что касается сетевого или системного программинга. А если взять работу с графикой (десктоп и т.п.), то там без тредов очень не емко получается. Можно конечно память расшаривать, но уж как-то
то сильно через одно место получается.
Так что что вы тут не говорите, а треды очень полезная вещь, правда использовать их нужно осторожно.

2 Losiki (23.03.2004 21:33:58):

kqueue в линуксе есть, сделали уже давно энтузиасты :) Правда, отдельным патчем. Я его, правда, не пользовал.

Зато теперь есть еще и epoll (), причем в обычном ядре с kernel.org

/vap

Вопрос - а если несколько процессоров, что лучше?

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

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

С уважением -- Смоляное Чучелко

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

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

> creare-pt: -p 1332 5.006 Seconds -- 266.057 processes/sec

Это какая-то лажа. Даже на дюроне в линуксе можно создать около десятка
тысяч процессов в секунду. Откуда такой левый тест? Что он делает?

А что касается спора тредов против процессов, есть хорошая цитата из
Алана Кокса:

There are really only two reasons for threaded programming.

- Poor programmer skills/language expression of event handling

- OS implementation flaws (and yes the posix/sus unix api has some of these)

Co-routines or better language choices are much more efficient ways to
express the event handling problem.

fork() is often a better approach than pthreads[...]

Золотые слова! В рамочку на стенку и читать перед сном 100 раз всем
любителям тредов!

А вот ещё классная цитата от Larry McVoy (автор BitKeeper):

"A computer is a state machine. Threads are for people who can't program state machines."

> Про тормоза - это еще вопрос.

Это не вопрос, это диагноз:

Ставим C++BuilderX. Смотрим на тормоза. Сносим. Ставим Zend Studio. Смотрим на тормоза. Сносим. Ставим Eclipse. Смотрим на тормоза. Хорошо бы тоже снести, да заменить нечем =)

> Так вот такое Г как жаба умрет как класс вместе с C#, C это всегда останеться.

К счастью, Java будет жить еще долго, по крайней мере пока не придумают полноценную замену JSP. Или ты предлагаешь web coding тоже на C?

Re:

А что, JSP - это единственное средство встраивать код в страницы? Хе-хе...

Вы, ребята, определенно гоните. Треды - полезнейшая весчь.
Для тех юмористов, предлагающих их заменить процессами, могу сообщить, что разделяя куски контекстов треды явно быстрее, чем процессы в свитчинге. Если вас пугают глюки в разделяемой памяти, то потрудитесь аккуратнее подходить к написанию приложений. Заверните треды в объекты, пускай у вас будет для каждого треда свой объект, все доступные переменные будут уникальные для треда. А для общей памяти выделите указатель на глобальный контекст и работайте с ним используя мьютексы или семафоры.
Для юмористов, приверженников select-ов и собственного шедулера: вы изобретаете велосипед. А более того, ваше рукоделие не будет параллелицца на 2 и более процессоров. И далеко не факт, что вы слабаете шедулер, который будет оптимальнее, чем линуховоядерный.
Идеальный случай использования тредов - простенький сервер. Используя треды можно очень легко реализовать workers-reuse, снизить оверхед на создание и синхронизацию всего этого дела, и, в то же время, распараллелить на несколько процессоров.
Так что не надо тут.

> Для юмористов, приверженников select-ов и собственного шедулера: вы изобретаете велосипед. А более того, ваше рукоделие не будет параллелицца на 2 и более процессоров. И далеко не факт, что вы слабаете шедулер, который будет оптимальнее, чем линуховоядерный.

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

Посмотрите на http://www.twistedmatrix.com

Это питоновская библиотека/фреймворк, которая позволяет такому ламеру как я "писать" клиент-серверные приложения промышленного качества.

Слава Дон-Кихотам.

>если OS9 "система реального времени" то я Жора Буш, самый что ни на есть ;-)))

Буш-отец или Буш-сын (а м. б. Буш-святой дух)?

> Откуда такой левый тест? Что он делает? http://www-106.ibm.com/developerworks/linux/library/l-rt7/?Open&t=grl,l=2...

to del: Полностью поддерживаю =)

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

Ну это уже для тех, кому делать нечего. Свой шедулер можно применять только в довольно маленьких приложениях, т.к. переключение контента вы с такой скоростью все равно не реализуеете (к примеру представьте себе ситуацию, когда у вас несколько рекурсивных функций и между ними надо переключаться). Я щас пишу мини-СУБД на тредах, и вы знаете, я доволен. И не нужно мне свой шедулер писать, который в ядре линукс уже имеется и работает гораздо лучше любого самопального.

P.S. По-моему, все эта критика в сторону тредов исключительно наследие однозадачных ОС. Если вам не нужна многозадачность, испоьзуйте ДОС =)

P.P.S. Вы думаете Apache2 зря перевели на треды? Или его тоже глупцы разрабатывали?

Кроме меньшего количества времени на переключение, потоки еще хороши тем, что позволяют свести практически к нулю проблемы передачи _достаточно_сложных_ структур данных между отцом/сыном. Требуется только синхронизация потоков. Особенно это касается программ на объектно-ориентированных языках, где достаточно передать указатель на объект. Только не надо разводить флейм по-поводу "А что лучше? С или С++?"

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

Просветите глупого, как с помощью fsm асинхронно вызывать gethostbyname? Не только сходить в DNS. Или вызвать rename(2)?

Переписать вызовы libc?

PS. Я знаю, что такое FSM (fsme.sf.net)

> Переписать вызовы libc?

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

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

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

> Я щас пишу мини-СУБД на тредах, и вы знаете, я доволен.

Кстати там и СУБД есть, mnesia называется, причём распределённая.