Представлен (http://lists.gnupg.org/pipermail/gnupg-announce/2012q2/00031...) первый выпуск новой свободной библиотеки для создания многопоточных приложений - nPth (http://git.gnupg.org/cgi-bin/gitweb.cgi?p=npth.git;a=summary) (New GNU Portable Threads Library). Изначально библиотека развивалась в рамках проекта GnuPG с целью создания более совершенной замены стандартной библиотеки GNU Pth (http://www.gnu.org/software/pth/), поддерживающей работу в современных операционных системах. Последний корректирующий релиз GNU Pth вышел в 2006 году, а последний значительный выпуск в 2004 году, c тех проект не развивается. Так как новая библиотека может представлять интерес и для других проектов, было принято решение развивать nPth в виде обособленного продукта. Код библиотеки распространяется под лицензиями LGPLv3 и GPLv2.
nPth предоставляет API, похожий на GNU Pth, и реализует невытесняющую модель организации работы нитей (non-preemptive, кооперативная многопоточность). Ключевым отличием от GNU Pth является уход от использования собственного диспетчера управления выполнением потоков в пользу стандартных системных реализаций многопоточности. Подобный подход позволяет использовать в приложениях библиотеки не совместимые с GNU Pth.
В программе GnuPG библиотека GNU Pth изначально активно использовалась для обеспечения выполнения вспомогательных сопрограмм. Реализуемая в GNU Pth концепция обеспечивала хорошую читаемость кода, соблюдение безопасность и простоту реализации. Но все достоинства GNU Pth меркли из-за необходимости придумывания "грязных хаков" при необходимости использования дополнительных библиотек, не совместимых с GNU Pth. Желание избавиться от этого недостатка и послужило главным стимулом для создания библиотеки nPth.
Истоки создания nPth начинаются с 2004 года, когда при портировании GnuPG 2 для Windows разработчики столкнулись с необходимостью замены библиотеки GNU Pth, которая не поддерживала данную платформу. Для решения проблемы была создана специальная надстройка над GNU Pth, эмулирующая работу API данной библиотеки, используя Windows API для многопоточности. Впоследствии данный подход показал, что подобная эмуляция является оптимальным способом обеспечения выполнения сопрограмм в GnuPG, особенно с учетом повсеместной поддержки pthreads на всех платформах.
В настоящее время на новую библиотеку уже переведена экспериментальная ветка GnuPG 2.1, поэтому проект nPth уже можно рассматривать как пригодный для повсеместного использования. Из остающихся недоработок, отмечается наличие проблем с переносимостью на некоторые редкие платформы. Но данные проблемы планируется решить к моменту выхода релиза nPth 1.0. На распространённых платформах, в том числе в Linux, kFreeBSD и Android, библиотека собирается и работает без нареканий. Что касается библиотеки GNU Pth, то судя по всему её дни сочтены - в настоящее время в репозитории Debian, кроме GnuPG, данная библиотека находится в зависимостях всего у двух пакетов - zhcon и jabberd14.
URL: http://lists.gnupg.org/pipermail/gnupg-announce/2012q2/00031...
Новость: http://www.opennet.me/opennews/art.shtml?num=33799
То есть на линуксе это будет просто оберткой вокруг pthread с другим API?
В линуксе нет тредов.
> В линуксе нет тредов.Не пишите глупости, есть. Это в «классическом» Unix-е был только fork. И то лет 20 тому назад.
>> В линуксе нет тредов.
> Не пишите глупости, есть. Это в «классическом» Unix-е был только fork. И
> то лет 20 тому назад.Нету. Именно как тредов - нету. Это для Linux вообще характерно во многих областях - есть подход всех обычных ОС, а есть как в линуксе. Например, везде кроме ядра есть понятие базовой системы ОС и сторонних программ - а в линуксе нету, там кроме ядра только пакеты.
Но вернемся к тредам. В типичных ОС (Windows, Solaris, FreeBSD) есть две раздельные сущности - процесс и тред (раздельные сущности с именами, например, struct proc и struct thread в ядре). Процесс имеет свое пространство виртуальной памяти, свой набор файловых дескрипторов, и др. атрибуты, особняком из которых стоят один или несколько тредов - просто поток исполнения со своим стеком и контекстом (набор регистров). Всё остальное принадлежит процессу.
В линуксе же всё - процесс. Тред в линуксе - просто легковесный процесс. В случае нескольких тредов в одном процессе эти нижележащие легковесные процессы просто разделяют (shared) те же самые атрибуты в виде пространства VM, дескрипторов и др. Собственно, если начало двухтысячных кто вспомнит, тогда даже в top можно бывало видеть артефакты этой реализации - многотредная программа показывалась как несколько процессов.
> Например, везде кроме ядра есть понятие базовой системы ОС и сторонних программ - а в линуксе нету, там кроме ядра только пакеты.Подобный подход является закономерным следствием слабого ресурсного обеспечения.
Например, в той же FreeBSD сравнительно мало активных мейнтейнеров, и они не могут эффективно поддерживать весь спектр ПО. Поэтому оно разделено на две категории: небольшая базовая система (с более-менее нормальной поддержкой, хотя в последние годы и она сильно сдала), и порты, которые поддерживаются нерегулярно, от случая к случаю.В крупных дистрибутивах GNU/Linux подобных проблем просто нет: практически все ПО, включая совершенно некритичное для системы в целом, поддерживается нормально - квалифицированный мейнтейнеров для этого достаточно.
Не является само по себе, базовая система как понятие развязана с проблемой ресурсов - это ж подход проектирования. У разработчиков коммерческих ОС, хотя бы тех же перечисленных комментом выше Solaris и Windows, тоже не хватает ресурсов? :)
В коммерческих ОС подобный подход диктуется принципом уменьшения расходов (и повышения прибыльности). Так что фактор ресурсов здесь тоже играет.Позволить себе полноценную поддержку обширных реп софта может только _крупный_ _некоммерческий_ проект.
> Тред в линуксе - просто легковесный процесс. В случае нескольких тредов в одном процессе эти нижележащие легковесные процессы просто разделяют (shared) те же самые атрибуты в виде пространства VM, дескрипторов и др.Это не в линуксе, это везде так. Тред от процесса как раз и отличается тем, что у тредов одного процесса общая память и дескрипторы (или "раздельные стек и контекст", что есть то же самое). Хоть в линухе, хоть в Solaris, хоть в BSD (не только FreeBSD), хоть в Windows. А одна структура у этих сущностей или же общая с разными атрибутами — не важно.
> Нету. Именно как тредов - нету. Это для Linux вообще характерно во
> многих областях - есть подход всех обычных ОС, а есть как
> в линуксе. Например, везде кроме ядра есть понятие базовой системы ОС
> и сторонних программ - а в линуксе нету, там кроме ядра
> только пакеты.Странно. На *моем* линуксе есть и пакеты, и сторонние программы. Может, вы пользуетесь каким-то не таким линуксом? Не говоря уже о том, что "подход обычных ОС" — ставить всё, что есть в репозиториях, из оных репозиториев. И в линуксе так, и в бсдях, и в солярке, и даже яблоко использует пусть и не идентичный подход, но близкий. Только винда выделывается.
> Странно. На *моем* линуксе есть и пакеты, и сторонние программы. Может, вы
> пользуетесь каким-то не таким линуксом? Не говоря уже о том, что
> "подход обычных ОС" — ставить всё, что есть в репозиториях, из
> оных репозиториев. И в линуксе так, и в бсдях, и в
> солярке, и даже яблоко использует пусть и не идентичный подход, но
> близкий. Только винда выделывается.Все же, в солярке и бсд существует четкое разделение: за базовую систему разработчики ручаются, а остальное пользователь ставит на свой страх и риск.
В линуксе, как правило, разработчики дистрибутива тянут поддержку всего софта.
> Все же, в солярке и бсд существует четкое разделение: за базовую систему разработчики ручаются, а остальное пользователь ставит на свой страх и риск.А где же по другому??? берем к примеру rhel, sles or ubuntu - за базовую систему разработчики ручаются
Поясни экспёрд, чем принципиально "легковесные процессы" отличаются от классических трэдов? И кстати, в русском языке нет слова "нету", грамотей.
> Собственно, если начало двухтысячных кто вспомнитС тех пор многое поменялось.
>> Собственно, если начало двухтысячных кто вспомнит
> С тех пор многое поменялось.В мире *BSD с тех пор не поменялось ничего. И они до сих пор считают себя лидерами среди свободных ОС :)
Лол, повылезали неграмотные тролли, одни не понимают, что важно, а что нет (следующий шаг - договоритесь до #5, который во всех ОС вообще одинаковый, а какая тогда разница, ага), другие не понимают разницы между сторонней программой вообще (есть ОС как цельный продукт, состоящая из ядра и его окружения, а есть все остальные сторонние программы) и способом её упаковки (тарбол с исходниками, пакет, поддерживаемый пусть и производителем репозиторий, какая разница, софт всё равно сторонний).А если кому правда интересно, как оно там внутри, я порекомендую хорошую книжку (по которой и пересказал выше) by Роберт Лав, "Разработка ядра Linux" (о сериях 2.6), http://www.ozon.ru/context/detail/id/2918313/
Ладно б базовая система vs пакеты. Можно ко всему в пакетах привыкнуть. Для кого-то это выглядит возможностью "поставить только нужное" (с наличием базовой системы так сделать никто не запрещает, я знаю ;).А вот дефолтное расположение баз того же мускуля в /var/lib и пустующий /var/db, отсутсвие документации (точнее, местами большие пробелы в ней), отсутствие init скрипта для svnserve - всё это бытовые мелочи, с которыми можно справиться и победить, но зачем, если можно по-нормальному? Единственное, что после каждой такой победы ЧСВ поднимается, да. :)
Не холивара ради (их тут разводить почти бессмысленно), а просто накипело. Peace.
Прально, там есть sys_clone(),
а sys_clone() это обертка для do_fork(),
do_fork() - обёртка для copy_process()
а copy_process() это замороченный malloc + куча флагов и блокировок.Фсё, пиз...ц, - ни форков, ни тредов не существует, есть:
...
mov eax, proc_data
jz new_proc
...Всех с победой!!!
Не совсем так, до победы ещё далеко.А вот thread'ов в Линуксе, действительно, нет, и вот почему: во всех нормальных операционных системах есть две операции -- создание процесса и создание потока исполнения. API и название функций значения не имеют -- имеет значение лишь то, что один процесс примерно в 5-6 раз медленнее другого.
Так вот, в Линуксе fork() и pthread_create() примерно равны, так сказать, "по тяжести". Собственно, именно поэтому в Линуксе thread'ов нет.
Ну линуксоиды же не виноваты, что не стали обвешивать и затормаживать fork(), как это сделано в "нормальных операционных системах".
> В линуксе нет тредов.И процессов тоже нет?
>> В линуксе нет тредов.
> И процессов тоже нет?Нет, сынок - это фантастика (с) Есть тригеры, которые стираются-записываются, а назвать ты это как хошь можешь.
И ложки тоже нет
ЛОМАЮЩИЕ НОВОСТИ
> В линуксе нет тредов.Поздравляю с разморозкой. Вы какого года заморозки, сэр?
>> В линуксе нет тредов.
> Поздравляю с разморозкой. Вы какого года заморозки, сэр?Написано же - начало двухтысячных. Кроме того, это, скорее всего, бсдшник, а они о линуксе знают только по страшным сказкам друзей-виндузятников.
Как показывает практика - таки линуксоиды знают о *BSD по страшным сказкам. А там всё нежно и _логично_, и _практично_. И есть хендбук, с которого можно легко начать.
Нежно-нежно, прямо как в макоси :)
Ну дыкть другой дистр попробуйте
> реализует невытесняющую модель организации работы нитейТак это нити (как ruby fibers) или все же потоки (threads)?
Если уж на то пошло, потоки - это streams. А threads - это волокна.
Знатоки, мля, словарь уже откройте.
Fibers - волокна, threads - нити.
> Если уж на то пошло, потоки - это streams. А threads - это волокна.Если уж на то пошло, в IT как-то так принято называть потоки инструкций именно тредами. Когда о например CPU говорят что там "2 hardware threads" - имеют в виду что он выполняет 2 потока команд одновременно. Как-то так, да. Термин "streams" почему-то не прижился. Вы лучше англичан знаете как им называть вещи на английском? :)
> Вы лучше англичан знаете как им называть вещи на английском? :)мы знаем лучше омерекосов как им называть вещи на английском.
типа фикс.
Stream тоже прижился, только он применяется к потоку информации. Видео например.
> Вы лучше англичан знаете как им называть вещи на английском? :)В этой области царит терминологический бардак, не зависящий от носителя языка.
это одно и то же
fiber (хз что там в руби нахерачели под этим понятием) = coroutines = green threads и почти = Non-preemptive threads, cooperative threads.Это все != threads
А где самое главное?
Код с примером использования.