Protothread для UNIX

> Larry Ruane адаптировал идею сверхлегких бесстековых нитей

Прочитал как "идею сверхлегких бестолковых идей". Надо спать :(.

> использует GCC label variables

вычисляемый goto, какая прелесть XD

уже можно кричать "ура" ?

это же Erlang идея, только там все ещё распределенно.

вроде как на сайте написано, что PROFIT-а не будет, кроме как Algorithm Clarity. так что не нужно.

Еще один способ, как добавить в прогу труднонаходимых ошибок с сомнительными выгодами.

Есть мнение, что треды не нужны.

>Есть мнение, что треды не нужны.

А что ты забыл тогда в этом треде? ^_^

Линукс уже не тот.

> Есть мнение, что треды не нужны.

Не нужны как альтернатива форкам? Или не нужны как концепция?

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

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

сказал так сказал...

накладные расходы много меньше, конечно же.

брожение умов
вроде линукс - зрелая система
а стандарт много-поточности до сих пор не устаканился

>Есть мнение, что треды не нужны.

Смотря где.
Изначальная идея Unix — использование процессов, а не тредов. Мода на треды пошла от VMS/Windows9x/NT, в которой создание дочернего процесса обходилась очень дорого, а создание треда внутри процесса ничего не стоило.

Опять же, треды могут использовать память процесса, в котором они родились, и конкурировать за локальные переменные/объекты процесса. А вот для взаимодействия отдельных процессов нужно использовать протоколы IPC — что накладно на не-Unix-машинах.

> вроде линукс - зрелая система а стандарт много-поточности до сих пор не устаканился

Уж лет 10-12 как устаканился.

RTFM - тред и процесс в Линуксе весят одинаково. Более того они оба очень легкие

>RTFM - тред и процесс в Линуксе весят одинаково. Более того они оба очень легкие.

Я про Unix говорил. Причём тут Linux?

> RTFM - тред и процесс в Линуксе весят одинаково

В каком FM ты это прочитал? O_o Я тоже хочу.

>вроде линукс - зрелая система а стандарт много-поточности до сих пор не устаканился

Это еще что... Сколько тысячелетий существует одежда, а до сих пор нет стандарта одежды, единого для тропической Африки и для Антарктиды..

> Я про Unix говорил. Причём тут Linux?

При том что в настоящем unix-е fork должен быть лёгким. И в linux это так и есть. А вот бсдя и в особенности соляра с их тяжеленными тормозными форками - ну ты понял, да?

\begin{troll}
треды не нужны!!!11 всем осиливать FSM!!!11
\end{troll}

>треды не нужны!!!11 всем осиливать FSM!!!11

покормить чтоли…

Роди, пожалста, автомат, который будет по процессорам вычисления раскидывать. И в котором блокирующие системные вызовы (см. getaddrinfo) ВНЕЗАПНО перестанут блокировать остальные операции.

>>Роди, пожалста, автомат, который будет по процессорам вычисления раскидывать. И в котором блокирующие системные вызовы (см. getaddrinfo) ВНЕЗАПНО перестанут блокировать остальные операции.

эээ... с каких под getaddrinfo сисколл? это же голимый glibc.


#define SYS_SOCKET 1 /* sys_socket(2) */
#define SYS_BIND 2 /* sys_bind(2) */
#define SYS_CONNECT 3 /* sys_connect(2) */
#define SYS_LISTEN 4 /* sys_listen(2) */
#define SYS_ACCEPT 5 /* sys_accept(2) */
#define SYS_GETSOCKNAME 6 /* sys_getsockname(2) */
#define SYS_GETPEERNAME 7 /* sys_getpeername(2) */
#define SYS_SOCKETPAIR 8 /* sys_socketpair(2) */
#define SYS_SEND 9 /* sys_send(2) */
#define SYS_RECV 10 /* sys_recv(2) */
#define SYS_SENDTO 11 /* sys_sendto(2) */
#define SYS_RECVFROM 12 /* sys_recvfrom(2) */
#define SYS_SHUTDOWN 13 /* sys_shutdown(2) */
#define SYS_SETSOCKOPT 14 /* sys_setsockopt(2) */
#define SYS_GETSOCKOPT 15 /* sys_getsockopt(2) */
#define SYS_SENDMSG 16 /* sys_sendmsg(2) */
#define SYS_RECVMSG 17 /* sys_recvmsg(2) */

вот весь перечень функций у socketcall.

Дык это ж сути не меняет. Кстати, неблокируемый аналог есть в библиотеке bind-а, запамятовал уже как называется.

читайте тролле

http://www.linuxjournal.com/article/3814

про веса и пр и пр

> Смотря где.
> Изначальная идея Unix — использование процессов, а не тредов.

Вот в этом смысле и не нужны. Это же и ответ товарищам выше.

>>про веса и пр и пр

заметьте, про вес я ни слова не сказал =]

Мдя ... кажись читать что такое эти prototreads так никто и не стал.
Это нифига не либа потоков или state-machine. Это скорее паттерн 
позволяющий более компактно/читабельно написать event-driven код.

> http://www.linuxjournal.com/article/3814

Двухтысячный год, Текстильщики, осень, ядра 2.0 2.2 2.4. Как оно там в анабиозе?

>эээ... с каких под getaddrinfo сисколл? это же голимый glibc

ты в каждом приложении будешь заново писать реализацию getaddrinfo? Всяческие libares давно находятся в полудохлом состоянии.

И про распределение нагрузки по процессорам — очень интересно.

В Linux еще кое-как теплятся черты классической UNIX. Обезабраженные донельзя опенсорсными внедренцами для имитации Windows и привлечения домохозяек и быдланов но, сцуки, теплятся. А пока они еще теплятся, треды под линуксом не будут любить.

>>Есть мнение, что треды не нужны.

>А что ты забыл тогда в этом треде? ^_^

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

http://www.linuxjournal.com/article/3814
классс! не ожидал

>>ты в каждом приложении будешь заново писать реализацию getaddrinfo? Всяческие libares давно находятся в полудохлом состоянии.

ну зачем же, можно и в библиотечку оформить.

>>И про распределение нагрузки по процессорам — очень интересно.

префорк N процессов + механизм балансировки по форкам; где N - кол-во ядер|процессоров.

P.S. google C10k problem

Linux — не Unix. Он больше на Windows похож по внедрению ядерных фишек aka WindowsNT касательно LWP (легковесных нитей ядра SVR4 1988г).

Unix'ы *BSD и Solaris берут своё начало от общего предка Unix 32v (1979г). *BSD кое-что оставила от BSD 1.0, когда ещё непосредственного предка Solaris — SVR4 не было и в помине, а UNIX(tm) не существовало.

Так к чему это я говорю,
Linux, как и Solaris, придерживается стандарта System V для выполнения системных вызовов fork и exec. То есть порождение процесса-потомка происходит при копировании структур процесса-родителя, при этом страницы памяти у них остаются общими до первого изменения страницы одним из процессов ДО вызова exec и exit. Что называется, "бронебойная защита памяти" порождающего и порождаемого процессов обусловливает и тормоза.

В *BSD другой, отличный от System V, принцип порождения процесса потомка: системный вызов vfork (спайка fork+exec) не копирует структуры процесса родителя и карты адресации, а приостанавливает процесс родителя и просто копирует регистры его карты адресации, далее запускает процесс-потомок и ждёт его окончания для возвращения управления в процесс родителя. Из-за того, что процесс родителя предоставляет своё адресное пространство процессу-потомку, вызов vfork выполняется гораздо быстрее тормознутых fork и exec в System V. Из-за отсутствия формальной защиты памяти процесса родителя, некоторые утилиты (csh, например) используют эту фичу.

Итоги
TruЪ — это vfork в *BSD.
Сrutchь — это fork System V & LWP SVR4/Linux.

> Итоги TruЪ — это vfork в *BSD. Сrutchь — это fork System V & LWP SVR4/Linux.

Главный итог - изень не знает про clone.

> Он больше на Windows похож по внедрению ядерных фишек aka WindowsNT касательно LWP (легковесных нитей ядра SVR4 1988г).

> TruЪ — это vfork в *BSD.

> Сrutchь — это fork System V & LWP SVR4/Linux.

Какая феерическая чушь.

> RTFM - тред и процесс в Линуксе весят одинаково. Более того они оба очень легкие

Это про нормальные полноценные процессы то? Которые "группа процессов" с одним процессом внутри? Ссылку!

>Главный итог - изень не знает про clone.

Эта ваша clone является подбием реализации TruЪ-*BSD'шного vfork что ли? Или способом признания костыльности/неэффективности/ собственной/линуксовой/ реализации fork из System V?

man 2 clone

СООТВЕТСТВИЕ СТАНДАРТАМ
Вызовы clone и sys_clone являются специфичными только для Linux, поэтому их не рекомендуется использовать в программах, предназначенных для последующего портирования. Для программирования многозадачных приложений (работающих в одном адресном пространстве) лучше всего использовать библиотеки, имеющие API стандарта POSIX 1003.1c, такие, как LinuxThreads library (включенную в glibc2).

> Эта ваша clone является подбием реализации TruЪ-*BSD'шного vfork что ли?

Почитал бы ты историю vfork, не позорился бы.

>Главный итог - изень не знает про clone.

Эта ваша clone является подобием реализации TruЪ-*BSD'шного vfork что ли? Или способом признания костыльности/неэффективности/ собственной/линуксовой/ реализации fork из System V?

man 2 clone

СООТВЕТСТВИЕ СТАНДАРТАМ
Вызовы clone и sys_clone являются специфичными только для Linux, поэтому их не рекомендуется использовать в программах, предназначенных для последующего портирования. Для программирования многозадачных приложений (работающих в одном адресном пространстве) лучше всего использовать библиотеки, имеющие API стандарта POSIX 1003.1c, такие, как LinuxThreads library (включенную в glibc2).

То есть "ещё одна Винда на подходе" — с таким отношением к идеям Unix. Как уже многие говорят про Linux: "Как бы Windows, но похоже на Unix".

> Эта ваша clone является подбием реализации TruЪ-*BSD'шного vfork что ли?

Нет, дорогой изень, с помощью этой вашей clone легко реализовать и fork, и vfork, а в 2.4 и треды на clone были сделаны. Вот что значит настоящая гибкость, не то что в допотопной бзде.

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

>Почитал бы ты историю vfork, не позорился бы.

Что, неужели vfork(2) произошло от clone(2)? :))

> треды не нужны!!!11 всем осиливать FSM!!!11

Аббревиатура FSM у мя ассоциируется с "конечный распознающий автомат"

>Нет, дорогой изень, с помощью этой вашей clone легко реализовать и fork, и vfork, а в 2.4 и треды на clone были сделаны. Вот что значит настоящая гибкость, не то что в допотопной бзде. 

clone(2) — чисто линуксовое изобретение не только для эмуляции vfork(2), но и для порождения потомков потоков уровня ядра и ещё кучи потенциально небезопасных вещей. Несовместимое ни с одним POSIX-стандартом.

Во FreeBSD используется libthr -- 1:1 POSIX threads library
DESCRIPTION
     The libthr library provides a 1:1 implementation of the pthread(3)
     library interfaces for application threading.  It has been optimized for
     use by applications expecting system scope thread semantics, and can pro-
     vide significant performance improvements compared to N:M Threading
     Library (libkse, -lkse).

>> Почитал бы ты историю vfork, не позорился бы.

> Что, неужели vfork(2) произошло от clone(2)? :))

Что, решил обратить всё в шутку?

http://www.cl.cam.ac.uk/cgi-bin/manpage?2+vfork:

"in the bad old days a fork() would require making a complete copy of the caller's data space,often needlessly, since usually immediately afterwards an exec() is done. Thus, for greater efficiency, BSD introduced the vfork system call, that did not fully copy the address space of the parent process, but borrowed the parent's memory and thread of control until a call to execve() or an exit occurred. The parent process was suspended while the child was using its resources. The use of vfork was tricky - for example, not modifying data in the parent process depended on knowing which variables are held in a register."

http://www.netbsd.org/docs/kernel/vfork.html:

"The Mach VM system added Copy On Write (COW), which made the fork() much cheaper, and in BSD 4.4, vfork() was made synonymous to fork(). After NetBSD 1.3, a traditional vfork() was reimplemented."

Есть здесь спецы по FreeBSD - там и сейчас vfork == fork?

P.S. а линуксовый clone - это наследник (не копия!) rfork из Plan9.

>Что, решил обратить всё в шутку?
>http://www.cl.cam.ac.uk/cgi-bin/manpage?2+vfork:

Да, я в курсе этого высказывания в манах Linux'а.
Торвальдс (или кто там среди пингвинов занимался многопоточностью?) просто НЕ_ОСИЛИЛИ реализацию vfork(2) иработу с ним в безопасном режиме — но всё-таки изобрели костыль_на_все_случаи_жизни — clone(2), так как fork(2) был для них слишком тормознутым/неэффективным/ потому что это наследие System V.

Торвальдс сам выбрал, какой ветке развития Unix подражать, вот и костыль clone(2) пришлось впоследствии изобретать и наворачивать на него ещё дополнительные функции для LWP в ядре — а что делать — управление pthreads в пространстве пользователя во времена изобретения Linux Kernel 2.4 работало куда тормозней шедулинга обычных процессов, а легковесные процессы ой как нужны были (чтобы конкурировать с Windows).

>Есть здесь спецы по FreeBSD - там и сейчас vfork == fork?

Они друг друга не заменяют. Во FreeBSD до сих пор это два отдельных вызова.

> Торвальдс (или кто там среди пингвинов занимался многопоточностью?) просто НЕ_ОСИЛИЛИ реализацию vfork(2) иработу с ним в безопасном режиме

Ыыыы... vfork _приостанавливает_ вызвавший его процес до момента выполнения exec: "The vfork() system call differs from fork(2) in that the child borrows the parent's memory and thread of control until a call to execve(2) or an exit". Он вообще не имеет отношения к многопоточности - там _не создается_ новый поток :D

> вот и костыль clone(2) пришлось впоследствии изобретать

Ты читать умеешь? clone - это видоизменный rfork, который изобрели в Plan9 (а потом реализовали и в FreeBSD).

Короче... перестань позорить честных бздешников.

> наворачивать на него ещё дополнительные функции для LWP в ядре — а что делать — управление pthreads в пространстве пользователя во времена изобретения Linux Kernel 2.4 работало куда тормозней шедулинга обычных процессов

И у тебя есть цифры, чтобы подтвердить это? :D

> Linux, как и Solaris, придерживается стандарта System V для выполнения системных вызовов fork и exec. То есть порождение процесса-потомка происходит при копировании структур процесса-родителя, при этом страницы памяти у них остаются общими до первого изменения страницы одним из процессов ДО вызова exec и exit. Что называется, "бронебойная защита памяти" порождающего и порождаемого процессов обусловливает и тормоза.

Тормоза были бы, если б память копировалась. А Linux использует COW, так что тормозов нетуть.

> В *BSD другой, отличный от System V, принцип порождения процесса потомка: системный вызов vfork (спайка fork+exec) не копирует структуры процесса родителя и карты адресации, а приостанавливает процесс родителя и просто копирует регистры его карты адресации, далее запускает процесс-потомок и ждёт его окончания для возвращения управления в процесс родителя.

Linux тоже умеет vfork. Но vfork годится только для последующего exec. И вообще для этого есть posix_spawn, пусть у него голова болит о том, использовать vfork, fork или что угодно ещё.

> TruЪ — это vfork в *BSD.

Костыль.

> Сrutchь — это fork System V & LWP SVR4/Linux.

Реализация fork оптимизирована. Как одной прогой грузить несколько CPU без потоков? Процессы плюс shm/mmap? Те же яйца, только в профиль и юзать неудобно.

Итоги

iZEN'у - тоньше троллить

>>Есть здесь спецы по FreeBSD - там и сейчас vfork == fork?

>Они друг друга не заменяют. Во FreeBSD до сих пор это два отдельных вызова.

_Твое_ мнение мы уже знаем :D