| Каталог документации / Раздел "Руководства по FreeBSD на русском" / Оглавление документа |
| |
|
4.4BSD поддерживает многозадачность. Каждая задача или выполняющийся поток называется процессом. Контекст процесса 4.4BSD состоит из состояния пользовательского уровня, включая содержимое его адресного пространства и окружения времени выполнения, и состояния уровня ядра, в который включаются параметры планировщика задач, управляющие ресурсы и идентифицирующая информация. В контекст включается все, что используется ядром при предоставлении своих сервисов процессу. Пользователи могут создавать процессы, управлять их выполнением и получать уведомления при изменении состояния выполнения процессов. Каждому процессу назначается уникальное число, называемое идентификатором процесса (PID). Это число используется ядром для идентификации процесса при сообщении пользователю об изменении его состояния, и пользователем для указания процесса в системном вызове.
Ядро создает процесс, дублируя контекст другого процесса. Новый процесс считается порожденным процессом исходного родительского процесса. Контекст, копируемый в ходе создания процесса, включает как состояние выполнения процесса уровня пользователя, так и системное состояние процесса, управляемое ядром. Важные компоненты состояния ядра описаны в Главе 4.
Жизненный цикл процесса изображен на Figure 2-1. Процесс может создать новый процесс, который является копией исходного процесса с помощью системного вызова fork. Возврат из вызова fork происходит два раза: один раз в родительском процессе, в котором возвращаемое значение является идентификатором порожденного процесса, и второй раз в порожденном процессе, в котором возвращаемое значение равно 0. Связь родитель-потомок порождает иерархическую структуру процессов в системе. Новый процесс имеет доступ ко всем ресурсам его родителя, таким, как файловые дескрипторы, состояние обработки сигналов и распределение памяти.
Хотя есть ситуации, когда процесс должен быть копией своего родителя, наиболее типичным и полезным действием является загрузка и выполнение другой программы. Процесс может заместить себя образом памяти другой программы, передавая вновь созданному образу набор параметров, при помощи системного вызова execve. Одним из параметров является имя файла, содержимое которого имеет формате, распознаваемый системой -- это либо двоичный выполняемый файл, либо файл, который приводит к запуску указанной программы интерпретации для обработки его содержимого.
Процесс может завершить работу, выполнив системный вызов exit, посылающий 8-битовое значение состояния завершения своему родителю. Если процесс хочет передать родительскому процессу информацию, превышающую один байт, он должен либо создать канал межпроцессных коммуникаций при помощи конвейеров или сокетов, или при помощи промежуточного файла. Коммуникации между процессами подробно обсуждаются в Главе 11.
Процесс может приостановить выполнение до тех пор, пока не завершит работу любой из порожденных им процессов, при помощи системного вызова wait, который возвращает PID и статус завершения выполненного дочернего процесса. Родительский процесс может быть настроен на получение сигнала в случае, когда порожденный процесс завершает работу или аварийно прекращает выполнение. При помощи системного вызова wait4 родитель может получить информацию о событии, приведшем к завершению порожденного процесса и о ресурсах, использованных процессом за время его работы. Если процесс становится сиротой из-за того, что процесс, его породивший, завершил работу до окончания работы потомка, то ядро перенаправляет состояние завершения порожденного процесса особому системному процессу init: обратитесь к разделам 3.1 и 14.6).
Подробное описание того, как ядро создает и уничтожает процессы, дается в Главе 5.
Планирование выполнения процессов осуществляется согласно параметру приоритетности процесса. Этот приоритет управляется алгоритмом планирования задач в ядре. Пользователи могут влиять на выполнение процесса, задавая этот параметр (nice), который влияет на суммарный приоритет, но но ограничен использованием ресурсов CPU согласно алгоритму планировщика задач ядра.
В системе определен набор сигналов, которые могут быть отправлены процессу. Сигналы в 4.4BSD сделаны по образу аппаратных прерываний. Процесс может определить пользовательскую подпрограмму, которая будет являться обработчиком, и которой должен будет перенаправляться сигнал. Когда сигнал генерируется, он блокируется от повторного появления до тех пор, пока не будет перехвачен обработчиком. Перехват сигнала включает в себя сохранение контекста текущего процесса и построение нового, в котором запускается обработчик. Затем сигнал направляется обработчику, который может либо прервать процесс, либо передать управление обратно выполняемому процессу (может быть, после установки значения глобальной переменной). Если обработчик возвратил управление, сигнал разблокировывается и может быть сгенерирован (и получен) снова.
Либо процесс может определить, что сигнал будет игнорироваться или будет выполняться действие по умолчанию, определяемое ядром. Действием по умолчанию для некоторых сигналов является прекращение процесса. Это завершение работы может сопровождаться созданием файла дампа, содержащего текущий образ памяти процесса для использования в последующей отладке.
Некоторые сигналы не могут быть перехвачены или проигнорированы. К таким сигналам относятся SIGKILL, прерывающий неуправляемый процесс, и сигнал управления заданиями SIGSTOP.
Процесс может выбрать получение сигналов в специальный стек для выполнения хитроумных программных манипуляций стеком. Например, подпрограммам поддержки языка нужно иметь стек для каждой подпрограммы. Система времени выполнения языка может выделять эти стеки, разделяя единственный стек, предоставляемый в 4.4BSD. Если ядро не поддерживает отдельный стек сигналов, то пространство, выделяемое каждой подпрограмме, должно быть расширено на объем, требуемый для перехвата сигнала.
Все сигналы имеют один и тот же приоритет. Если обработки ожидают несколько сигналов, то порядок их направления процессу зависит от реализации. Обработчики сигналов, выполняемые по сигналу, который их вызвал, блокируются, но при этом могут быть сгенерированы дополнительные сигналы. Имеется механизм, позволяющий защитить критический участок кода от появления заданных сигналов.
Подробное описание архитектуры и реализации механизма сигналов дается в Разделе 4.7.
Процессы организованы в группы управления. Группы управления используются для управления доступом к терминалам и для обеспечения передачи сигналов наборам связанных процессов. Процесс наследует группу управления от своего родительского процесса. Ядром обеспечиваются механизмы, позволяющие процессу изменять свою группу управления или группу управления своих наследников. Создание новой группы управления просто; значение, соответствующее новой группе управления, обычно является идентификатором создающего ее процесса.
Группу процессов в группе управления иногда называют заданием и оно управляется высокоуровневым системным программным обеспечением, таким, как командный процессор. Типичным примером задания, созданного командным процессором, является конвейер из нескольких связанных процессов, так что выходной поток первого процесса является входным потоком для второго, выходной поток второго процесса является входным потоком для третьего, и так далее. Командный процессор создает такое задание, порождая процесс для каждого участка конвейера, а затем помещая все эти процессы в отдельную группу обработки.
Пользовательский процесс может послать сигнал как всем процессам в группе управления, так и конкретному процессу. Процесс в заданной группе управления может получать программные прерывания, отражающиеся на группе, приводящие к приостановке или продолжению выполнения, или к прерыванию или завершению работы.
Терминалу ставится в соответствие идентификатор группы управления. Этот идентификатор обычно равен идентификатору группы управления, соответствующей терминалу. Управляющий заданиями командный процессор может создать несколько групп управления, связанных с одним и тем же терминалом; терминал является управляющим терминалом для каждого процесса в этих группах. Процесс может выполнять чтение из дескриптора своего управляющего терминала, если только идентификатор группы управления соответствует идентификатору группы этого процесса. Если идентификаторы не совпадают, процесс будет блокирован при попытке чтения с терминала. Изменяя идентификатор группы управления терминала, командный процессор может распределять терминал между несколькими различными заданиями. Такое распределение называется управлением заданиями и описывается вместе с группами управления в Разделе 4.8.
Так же, как и наборы связанных процессов могут объединяться в группы управления, набор групп управления может быть объединен в сеанс. Основное назначение сеансов заключается создании изолированного окружения для процесса-даемона и порожденных им процессов, а также для объединения начального командного процессора пользователя и заданий, которые он порождает.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |
