Это множество форм записи отличается синтаксисом, который определяет формат списка аргументов командной строки, полученного нами в качестве параметров функции
main()
, передаваемых программе, а также некоторыми другими дополнительными деталями. Суффиксы в именах функций обозначают следующее:
•
l
— список аргументов определяется через список параметров, заданных непосредственно в самом вызове. Этот список завершается нулевым аргументом
NULL
;
•
e
— окружение для процесса указывается посредством определения массива переменных окружения;
•
p
— относительный путь поиска: если не указан полный путь к файлу программы (то есть имя файла не содержит разделителей «
/
»), для его поиска используется переменная окружения
PATH
;
•
v
— список аргументов определяется через указатель на массив аргументов.
В нашу задачу не входит описание всех возможностей вызовов, тем более что они обстоятельно описаны в [1, 2, 5, 6], и мы будем использовать по тексту любую, более удобную для нас форму без дополнительных объяснений.
Большинство форм функции
exec()
являются POSIX-совместимыми, а большая часть форм функции
spawn()
представляет собой специфическое расширение QNX. Более того, даже для тех функций группы
spawn()
, которые часто называют POSIX-совместимыми [1], техническая документация QNX определяет степень совместимости примерно в таких терминах: «
Функции семейства
exec()
, напротив, подменяют исполняемый код текущего процесса (не изменяя его идентификатор PID, права доступа, внешние ресурсы процесса, а также находящийся в том же адресном пространстве) исполняемым кодом из другого файла. Поэтому используются эти вызовы непосредственно после
fork()
для замены копии вызывающего процесса новым (это классическая UNIX-технология использования).
Функции семейства
spawn()
, напротив, порождают новый процесс (с новым идентификатором PID и в новом адресном пространстве). Все формы вызовов spawn() после подготовительной работы (иногда очень значительной) в конечном итоге ретранслируются в вызов базовой формы
spawn()
[13], который последним действием своего выполнения и посылает сообщение
procnto
(менеджер процессов QNX, «территориально» объединенный с микроядром системы в одном файле).
Базовый вызов
spawn()
определяется следующим образом:
#include
pid_t spawn(const char* path, int fd_count, const int fd_map[],
const struct inheritance* inherit, char* const argv[],
char* const envp[]);
где
path
— полное имя исполняемого бинарного файла;
fd_count
— размерность следующего за ним массива
fd_map
;
fd_map
— массив файловых дескрипторов, которые вы хотели бы унаследовать в дочернем процессе от родительского. Если
fd_count
не равен 0 (то есть может иметь значения вплоть до константы
OPEN_MAX
), то
fd_map
должен содержать список из
fd_count
файловых дескрипторов. Если же
fd_count
равен 0, то дочерний процесс наследует все родительские дескрипторы, исключая те, которые созданы с флагом
PD_CLOEXEC
функции
fcntl()
;
inherit
— системная структура (см. системные определения) типа
struct inheritance
, содержащая как минимум:
unsigned long flags
— один или более установленных бит:
SPAWN_CHECK_SCRIPT
— позволить
spawn()
запускать требуемый командный интерпретатор, интерпретируя
path
как скрипт (интерпретатор указан в первой строке скрипта
path
);
SPAWN_SEARCH_PATH
— использовать переменную окружения
PATH
для поиска выполняемого файла
path
;
SPAWN_SETGROUP
— установить для дочернего процесса значение группы, специфицируемое членом (структуры)
pgroup
. Если этот флаг не установлен, дочерний процесс будет частью текущей группы родительского процесса;
SPAWN_SETND
— запустить дочерний процесс на удаленном сетевом узле QNET, сам же удаленный узел специфицируется членом (структуры)
nd
(см. команду удаленного запуска
on
);
SPAWN_SETSIGDEF
— использовать структуру
sigdefault
для определения процесса множества (набора) сигналов, для которых будет установлена реакция по умолчанию. Если этот флаг не установлен, дочерний процесс наследует все сигнальные реакции родителя;
SPAWN_SETSIGMASK
— использовать
sigmask
в качестве сигнальной маски дочернего процесса.