CreateProcess популярнее. (c) ru.os.cmp FAQ с вариациями :)

Правда, не под Linux.

Зависит от поставленной задачи....

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

Шреды легше, проще, общая память - и поэтому надо самому следить чтоб они друг другу не нагадили.

Что значит <fork хуже переносим> ?

AIv (17.02.2005 19:26:00):

> с fork-ом больше возни, больше жрет ресурсов,

По крайней мере спорные утверждения. IMHO наоборот.

>сложнее обмениваться инф-ей,

IMHO единственное справедливое утверждение

> хуже переносим

Вызывающе неверная информация :-)

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

IMHO В 90% случаев форк предпочтительнее.

За что купил - за то и продаю:

>> с fork-ом больше возни, больше жрет ресурсов,

>По крайней мере спорные утверждения. IMHO наоборот.

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

>> хуже переносим

>Вызывающе неверная информация :-)

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

))))))))))))) То есть несмотря на отсутвие на нек-х платформах (всех виндовс) форков, форк переносим таки лучше? ))))))))))

>IMHO В 90% случаев форк предпочтительнее.

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

2анонимус - в том смыслек хучже переносим, что под виндовс форк вообще не переносим. Нету его там......

2AIv :

> То есть несмотря на отсутвие на нек-х платформах (всех виндовс) форков, форк переносим таки лучше?

Да.

Форк -- он и в Африке форк. Одинаково работает везде, кроме Вындуза. А с трэдами намаешься, они везде свои. Даже в Линухе их много разных.

"всех виндовс" -- хорошо сказал :-)

ну тут я ничего сказать не могу

поскоку ничего не знаю)))))) Мне хватает линуха. Тем более что меня тешет смутная надежда что питоновские шреды и в африке питовновские шреды... а больше мне ничего не нужно))))

>2анонимус - в том смыслек хучже переносим, что под виндовс форк
>вообще не переносим. Нету его там......

Его там несложно сделать. Ну и, вообще говоря, он там есть (но не как часть Win32 API). :)

Murr:

>> 2анонимус - в том смыслек хучже переносим, что под виндовс форк вообще не переносим. Нету его там......

> Его там несложно сделать.

Однако, помнится, David Korn отмечал, что именно реализация форка для него оказалась одним из самых сложных моментов.

>Однако, помнится, David Korn отмечал, что именно реализация форка для
>него оказалась одним из самых сложных моментов.

Она требует знания недокументированной прослойки между API и ядром, т.н. native API. Реализация fork() есть в книге Гэри Небета ("Windows 2000 Native API") как пример к одной из глав.

Существуют и родные (от MS) реализации fork() в составе одной из коммер ческих реализациях POSIX subsystem.

Ну и вопрос... Вообще говоря это ортогональные понятия. И спрашивать что лучше а что хуже... Ерунда какая-то :)

> Вообще говоря это ортогональные понятия.

поясни

>Что лучше: потоки или fork?

А для чего?

Вообще говоря, если есть возможность обойтись fork -- лучше fork, ибо в программе с форком сложнее сделать ошибку. Упадет потомок -- и фиг с ним! Упадет второй тред -- попортит данные. Опять же, race condition между сепаратными процессами сложнее устроить.

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

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