Хм, пожалуй Вы правы. Хотя, чтобы исполнять недоверенный код и предоставлять ему содержимое собственной памяти нужно быть достаточно осторожным, но таки да здесь fork будет быстрее. С друой стороны для нагруженных серверов он все равно недостаточно быст и тот же apache создает пул процессов до начала обработки запросов. В данном случае не так существенно будет ли холодный старт занимать 100 миллисекунд или 1000.
Далее, usecase, в котором скорость программы зависит от скорости fork настолько редок и специален
Кстати, оппонент не может привести такого примера — может хоть Вы мне приведете пример, когда использование fork может быть оправдано (я правда не знаю)
Вы, похоже, совершенно не представляете, что делает fork. Это потокам не нужно дополнительное адресное пространство. форк же, помимо собственно создания все той же единицы исполнения, должен создать адресное пространство (на x86 это PDE/PTE таблицы)
Во первых, при чем здесь «context switches»? Я говорю о создании. Во вторых не верю — мне бы чего нибудь посолиднее, чем мнение линукс евангелиста на какой то никому неизвестной дискуссионной борде. Хотя бы потому, что единственное отличие со стороны скедьюлера будет в том нужно перегружать адресное пространство (cr3 x86) или нет. При перезагрузке cr3 сбрасываются все TLB, что приводит к необходимости перезаполнять их каждый раз. То есть к совершенно не имеющему отношения собственно переключению контекстов добавляется гигантский оверхед на необходимость лезть каждый раз в память.
Вообще-то, там, где есть форк, больше распространены процессы.
Вообще то там, где волнуются о производительности больше распространены потоки, которые не только легче сами по себе, так еще и избавляют от расходов на IPC.
Насчет mach я не совсем понял, это ведь вроде микроядро
И что? Когда само по себе — микроядро, когда в составе XNU — гибридное. Это что-то меняет?
Это к тому, что потоки появились, хм… несколько раньше NT.
И, да, практически у всех коммерческих ОС были потоки до появления pthread-ов. Вот, к примеру, солярка: docs.sun.com/app/docs/doc/806-6867/sthreads-10606?l=ja&a=view
Ну вот сейчас я пишу сервер на процессах: тысячи fork() и ни одного vfork() или exec().
Ну да, Вы пишете многопоточное приложение. Я же просил привести пример, когда форк дает какую либо выгоду по сравнению с vfork/exec и pthread_create (Ну или по сравнению c CreateProcess/CreateThread, если угодно).
Скажу более, создание стапиццот единиц исполнения может привести к ЗАМЕДЛЕНИЮ исполнения (особенно на линуксовых скедьюлерах, которые меняются раз в пару лет, а толку никакого). Именно поэтому для виндового IOCP рекомендуется (и по умолчанию ставится) количество рабочих потоков, не превышающих количества процессоров.
На Линукс нет такого соотношения именно за счет скорости форк.
Нет. Во первых я мерял. Форк был около 700к тактов на линуксе. CreateThread — меньше 100к. Во вторых это очевидно. CreateThread создает пару структур в ядре и все. fork — инициализирует новое адресное пространство, копирует все дескрипторы и делает еще туеву хучу ненужной работы.
А области где отдельный процесс лучше, чем треды известны
Опять лозунги. Я же вроде бы попросил конкретный use case. Я не вижу никаких проблем ни с безопасностью, ни с простотой, ни с надежностью.
> А скорость — это одна из основных черт форка-а и есть.
Создание потока примерно в 10 раз «легче» создания форка. Если же учесть последующий exec, то виндовый CreateProcess как бы не легче такой парочки оказался.
Ах, да
3. Что будем делать с тем же mach, в котором все те же процессы (task) и потоки (threads)? Странным образом он появился раньше NT. Причем в той же MacOSX для скедьюлинга используется именно mach — без всякой винды. «Потоки» распространены потому, что они лучше разделяют абстракции и являются более хорошим решением во всех сценариях использования
1. А Win32 подсистема Вам значит нужна из POSIX?
2. vfork годится потому что в подавляющем большинстве случаев следом идет exec*. Про «именно поэтому» я бы перефразировал: именно потому, что fork не отвечал современным требованиям к параллельным вычислениям и появились pthread-ы.
Я, к примеру, вот так сходу не могу придумать примера, когда использование fork оправдано — всегда либо создание процесса fork/exec, либо все те же «потоки», но в отдельном (скопированном) адресном пространстве. Можете привести хотя бы один usecase когда fork справляется лучше, чем даже pthreads (и не забывайте, что создание потока примерно в 10 раз дешевле форка)?
Добавлю
1. Но можно (очевидно) достучаться до Native подсистемы, поверх которой реализованы и POSIX и Win32 — никаких проблем
2. Fork действительно плохо ложится на архитектуру NT (пожалуй единственный позиксовый системный вызов), но во первых есть vfork, который ложится идеально и даже работает быстрее, покрывая при это подавляющее большинство usecase-ов fork-а, а во вторых нынешним «модным трендом» является использование потоков, которые тоже элементарно реализуются в NT.
А удивился я как раз тому факту, что при наличии «мертвых клавиш», в раскладке все равно до хрена символов с этой самой диакритикой — вне этих самых «мертвых клавиш»
ваш собеседник привел пример несоответствия API Windows стандарту (ну или рекомендации) POSIX.
Вы правда не читали? Напоминаю:
> posix api гораздо удобнее в использовании, чем win api.
> Хорошо бы пример. А то, знаете ли, у меня совершенно другие ощущения
> Посмотри, например, pthreads.
О боже. Невозможно? Откуда ж столько портов?
Оттуда такие штуки как Cygwin и MSYS, как бы среды для компиляции unix-программ под виндой
Эх, вот если бы люди говорили только о вещах в которых разбираются. Мечты, мечты…
Это не говорит, что API для работы с тредами в винде лучше или хуже, а говорит про то, что интерфейс был урезан до минимума приличий.
О пресвятая Гаечка. Даже если бы Ваше предыдущее утверждение имело хоть какой то смысл, отследить логическую связь с вот этим вот бредом невозможно.
Мало того, что pthread-ы полностью реализованы в SUA. Но хуже всего то, что ВСЕ pthread-овые вызовы — крайне примитивное подмножество виндовых потоков. К тому же, как я уже сказал, неконсистентное и неудобное.
Кстати, наткнулся только что на готовую раскладку, в которой на «мертвых клавишах» (и не только) замаплено просто дикое количество символов: www.aimwell.org/Fonts/Keyboards/keyboards.html
Подозреваю, что имелось в виду «обучение» не у «менеджеров по продажам», а у покупателей. В транспорте Оззи тоже ездит для того, чтобы посмотреть на «реальный мир».
В каждой большой организации есть немало интересных людей. Это статистически очевидно.
В Apple и Google или там IBM или Intel — все то же самое (с поправкой на некоторые корпоративные традиции) — умные и интересные люди работают над сложными и интересными вещами. По крайней мере на инженерном направлении, маркетинговые отделы отличаются очень сильно
Кстати, оппонент не может привести такого примера — может хоть Вы мне приведете пример, когда использование fork может быть оправдано (я правда не знаю)
Вообще то там, где волнуются о производительности больше распространены потоки, которые не только легче сами по себе, так еще и избавляют от расходов на IPC.
Насчет mach я не совсем понял, это ведь вроде микроядро
И что? Когда само по себе — микроядро, когда в составе XNU — гибридное. Это что-то меняет?
Это к тому, что потоки появились, хм… несколько раньше NT.
И, да, практически у всех коммерческих ОС были потоки до появления pthread-ов. Вот, к примеру, солярка: docs.sun.com/app/docs/doc/806-6867/sthreads-10606?l=ja&a=view
Ну да, Вы пишете многопоточное приложение. Я же просил привести пример, когда форк дает какую либо выгоду по сравнению с vfork/exec и pthread_create (Ну или по сравнению c CreateProcess/CreateThread, если угодно).
Скажу более, создание стапиццот единиц исполнения может привести к ЗАМЕДЛЕНИЮ исполнения (особенно на линуксовых скедьюлерах, которые меняются раз в пару лет, а толку никакого). Именно поэтому для виндового IOCP рекомендуется (и по умолчанию ставится) количество рабочих потоков, не превышающих количества процессоров.
На Линукс нет такого соотношения именно за счет скорости форк.
Нет. Во первых я мерял. Форк был около 700к тактов на линуксе. CreateThread — меньше 100к. Во вторых это очевидно. CreateThread создает пару структур в ядре и все. fork — инициализирует новое адресное пространство, копирует все дескрипторы и делает еще туеву хучу ненужной работы.
А области где отдельный процесс лучше, чем треды известны
Опять лозунги. Я же вроде бы попросил конкретный use case. Я не вижу никаких проблем ни с безопасностью, ни с простотой, ни с надежностью.
Создание потока примерно в 10 раз «легче» создания форка. Если же учесть последующий exec, то виндовый CreateProcess как бы не легче такой парочки оказался.
3. Что будем делать с тем же mach, в котором все те же процессы (task) и потоки (threads)? Странным образом он появился раньше NT. Причем в той же MacOSX для скедьюлинга используется именно mach — без всякой винды. «Потоки» распространены потому, что они лучше разделяют абстракции и являются более хорошим решением во всех сценариях использования
2. vfork годится потому что в подавляющем большинстве случаев следом идет exec*. Про «именно поэтому» я бы перефразировал: именно потому, что fork не отвечал современным требованиям к параллельным вычислениям и появились pthread-ы.
Я, к примеру, вот так сходу не могу придумать примера, когда использование fork оправдано — всегда либо создание процесса fork/exec, либо все те же «потоки», но в отдельном (скопированном) адресном пространстве. Можете привести хотя бы один usecase когда fork справляется лучше, чем даже pthreads (и не забывайте, что создание потока примерно в 10 раз дешевле форка)?
1. Но можно (очевидно) достучаться до Native подсистемы, поверх которой реализованы и POSIX и Win32 — никаких проблем
2. Fork действительно плохо ложится на архитектуру NT (пожалуй единственный позиксовый системный вызов), но во первых есть vfork, который ложится идеально и даже работает быстрее, покрывая при это подавляющее большинство usecase-ов fork-а, а во вторых нынешним «модным трендом» является использование потоков, которые тоже элементарно реализуются в NT.
А «символы как é и ü» — это «символы с диакритикой»: en.wikipedia.org/wiki/Diacritic
А удивился я как раз тому факту, что при наличии «мертвых клавиш», в раскладке все равно до хрена символов с этой самой диакритикой — вне этих самых «мертвых клавиш»
Вы правда не читали? Напоминаю:
> posix api гораздо удобнее в использовании, чем win api.
> Хорошо бы пример. А то, знаете ли, у меня совершенно другие ощущения
> Посмотри, например, pthreads.
О боже. Невозможно? Откуда ж столько портов?
Оттуда такие штуки как Cygwin и MSYS, как бы среды для компиляции unix-программ под виндой
Эх, вот если бы люди говорили только о вещах в которых разбираются. Мечты, мечты…
Это не говорит, что API для работы с тредами в винде лучше или хуже, а говорит про то, что интерфейс был урезан до минимума приличий.
О пресвятая Гаечка. Даже если бы Ваше предыдущее утверждение имело хоть какой то смысл, отследить логическую связь с вот этим вот бредом невозможно.
Мало того, что pthread-ы полностью реализованы в SUA. Но хуже всего то, что ВСЕ pthread-овые вызовы — крайне примитивное подмножество виндовых потоков. К тому же, как я уже сказал, неконсистентное и неудобное.
www.aimwell.org/Fonts/Keyboards/keyboards.html
Зато легко добавить себе любые удобные комбинации (я на ноутбучный бекслеш — который слева — повесил dead key и докидываю туда недостающие символы) msdn.microsoft.com/en-us/goglobal/bb964665.aspx
В Apple и Google или там IBM или Intel — все то же самое (с поправкой на некоторые корпоративные традиции) — умные и интересные люди работают над сложными и интересными вещами. По крайней мере на инженерном направлении, маркетинговые отделы отличаются очень сильно