здравствуйте вычитал в Роберта Лава в книжечке "Разработка ядра Linux", что новый процесс создается вот как: сначала вызывается fork, который создает копию порождающего процесса, затем уже туда помещается код исполняемого файла, который надо выполнять. ну зачем так? разве нельзя было просто выделить память, _сразу_ поместить туда то, что надо и выполнять. почему сначала копия создаваться должна? может я просто не так понял.... зачем копию эту? это ведь только скорость создания процесса снижает, наверно, а плюсы у этого есть?
Интересный вопрос, я тоже над этим задумывался. Единственное предположение, которое у меня есть -- раньше это позволяло сэкономить на обращении к жесткому диску, в случае, если программа хочет запустить еще одну копию себя, а не другую программу. Однако, это всего лишь предположение.
Потерь там как токовых нет потомучто если сразу вызвать exec или как онт там фактически это ровно изначальному созданию процесса. А нужно это затем чтобы не париться со всякими межпроццессорными взаимодействиями вроде, я сам еще не до конца вкурил, но найду статью кину.
fork - можно использовать как интерфейс к механизму создания процессов. К примеру, если вы используете язык PHP, то в Unix-версии там есть fork - очень удобно вместо exec php -f ...
Из книги Стивенса: Advanced programming in the unix environment. Порядок вызова и возвращаемые значения функций vfork и fork одинаковы, но семантика этих двух функций различается. Функция vfork впервые появилась в 2.9BSD. Некоторые считают эту функцию пятном на репутации UNIX, однако все платформы, обсуждаемые в этой книге, поддерживают ее. Фактически разработчики удалили vfork из версии 4.4BSD, но все дистрибутивы BSD с открытыми исходными текстами, происходящие ot4.4BSD, восстановили ее поддержку. В третьей версии Single UNIX Specification функция vfork отмечена как устаревший интерфейс. Функция vfork предназначена для создания новых процессов, когда целью нового процесса является запуск новой программы с помощью функции exec (пункт 2 в конце предыдущего раздела). Программа из листинга 1.5 также относится к программам этого типа. Функция vfork создает новый процесс точно так же, как fork, но не копирует адресное пространство родительского процесса в адресное пространство потомка, поскольку потомок не будет работать с этим адресным пространством - он просто вызывает функцию exec (или exit) сразу же после того, как vfork вернет управление.
letopisec fork и сразу exec, получитаться по производительности тоже самое что и vfork, ну мб совсем чуть чуть лучше тк реаьного копировния всеравно не происходит.Так что правда в вфорке смысла нету ))
создание нового процесса и "помещается код исполняемого файла" - это разные понятия, которые реализуются двумя разными системными вызовами sys_clone() и sys_execve() в Linux как и в большинстве юниксоподобных систем создание процесса и отображение исполняемого файла разделены
sys_clone и sys_fork вещи разные. Первый для многопоточности был создан. Cмысл в том что при системном вызове sys_clone ресурсы у потомка те же, что и у родителя - различия обязательные только в стеке, остальное опционально. А вот у fork'а с родителем разница бОльшая - совместно используются только разделяемые (shared) ресурсы. Копирование памяти от родителя к потомку в обоих случаях происходит при записи (copy-on-write), поэтому особых расходов не требуется. А кому потомок в таком случае будет принадлежать? Init'у?! А какие права он получит?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/arch/x86/kernel/process_64.c#L704 где разница sys_clone() - обобщение sys_fork() libc использует вызов sys_clone() для эмуляции fork() для реализации NPTL был добавлен флаг CLONE_THREAD (в 2.4.0-test8), а не sys_clone() родительскому процессу в чем проблема
увеличиваются счетчики ссылок у большинство ресурсов, инкапсулированных в структуре struct task_struct процесса, в контексте которого идет вызов clone() в том числе у структуры адресного пространства struct mm_struct
rei3er А есть там аналог CreateThread ? И еще интересно, как там с ГУИ. Есть ли аналоги CreateWindowEx, DialogBoxParam и т.д?
Это два разных системных вызова, стало быть sys_clone никак не зависит от sys_fork и наоборот. К тому же sys_clone специфичен для линукса. До NPTL тоже были потоки - LinuxThreads. Я интерпретировал вопрос топикстартера в форме: "Зачем нужно наследование, которое делает fork?" Сообразно этому и отвечал. Я что-то неправильно понял? Графики в ядре нет. Эти функции предоставляются системой x-window и далее различными абстракциями qt, gtk, wxwidgets и прочее.
мы говорим вполне про конкретную ОС Linux применительно к ней sys_clone() - обобщение sys_fork() т. е через флаги clone() может реализовывать fork() ну и? что, тогда не было системного вызова sys_clone()? NPTL = CLONE_THREAD в sys_clone()
Хорошо, уговорил. Функционально clone обобщает fork. Я же говорил, для реализации многопоточности (LinuxThreads) был создан этот вызов. Когда не было поддержки на стороне ядра, треды реализовывались на уровне пользователя (прототреды, как пример). Вернусь к твоей фразе. Я изначально не упоминал про NPTL.
