Порожденный процесс
Cтраница 1
Порожденный процесс наследует все файлы, открытые его отцом. [1]
Порожденный процесс наследует все текущие типы реакции на сигналы порождающего процесса. [2]
Порожденный процесс остается в памяти системы, пока не завершатся все его потоки ( нити), и пока все его дескрипторы не закроются вызовом CloseHandle. Если эти дескрипторы не нужны, лучше всего закрыть их сразу после инициализации процесса. [3]
 |
Дерево процессов в системе UNIX. [4] |
Часто порожденный процесс определенным образом дезориентирует дескрипторы файлов, а затем выполняет системный вызов exec, который замещает его программу и данные программой и данными из выполняемого файла, определенного в качестве параметра к вызову exec. Например, если пользователь печатает команду xyz, то интерпретатор команд ( оболочка) выполняет операцию fork, создавая таким образом порожденный процесс. [5]
В приведенном ниже примере порожденный процесс пытается выполнить программу prog, а процесс, породивший его, ждет его завершения. [6]
Функция WaitForlnputldle возвращается, если истекло время ожидания, или когда порожденный процесс инициирован и ждет ввода со стороны пользователя. [7]
В этом примере, как в исходном, так и в порожденном процессе, для перезаписи используется один и тот же буфер. В действительности после разделения процессов области данных тоже разделяются и становятся независимыми. [8]
Объясним, почему локальная куча SRO распределяется для стеков SRO при использовании порожденных процессов. При выполнении в одном частном контексте родитель может породить более одного процесса. Более того, порядок создания и завершения в этом контексте порожденных процессов не может быть определен во время компиляции. Следовательно, слежение за стеками SRO, связанными с активизированными порожденными процессами, требует особой стратегии управления кучей. Таблица объектов в стеке SRO процесса-родителя не может использоваться для отслеживания этих процессов. [9]
 |
Параллельная обработка с несколькими процессорами ( а. моделирование. [10] |
В одних случаях исходный процесс сохраняет частичный или даже полный контроль над порожденным процессом. Виртуальные команды позволяют исходному процессу останавливать и снова запускать, проверять и завершать подчиненные процессы. В других случаях исходный процесс никак не контролирует порожденный процесс: после того как новый процесс сформирован, исходный процесс не может его остановить, запустить заново, проверить или завершить. Таким образом, эти два процесса работают независимо друг от друга. [11]
Эти два процесса работают параллельно, но иногда порождающий процесс должен по каким-либо причинам ждать, чтобы порожденный процесс завершил свою работу, и только после этого продолжать выполнение тех или иных действий. [12]
На логическом уровне стек SRO, предоставленный для корневого процесса, служит как фонд, из которого берутся ресурсы для использования каждым порожденным процессом. Для тех, кто интересуется этим вопросом, ниже мы рассмотрим физические взаимосвязи. Когда задача выдает явный или неявный запрос на создание новой задачи, требуемые для соответствующего порожденного процесса ресурсы только логически распределяются из локальной кучи SRO, созданной родителем. [13]
Чтобы процесс мог опознать, является он отцом или сыном, системный вызов fork возвращает в качестве своего значения в породивший процесс идентификатор порожденного процесса, а в порожденный процесс - нуль. [14]
Чтобы процесс мог опознать, является он отцом или сыном, системный вызов fork возвращает в качестве своего значения в породивший процесс идентификатор порожденного процесса, а в порожденный процесс - нуль. [15]
Страницы: 1 2 3 4