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