Это множество форм записи отличается синтаксисом, который определяет формат списка аргументов командной строки, полученного нами в качестве параметров функции 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
в качестве сигнальной маски дочернего процесса.