Правила наследования (и ненаследования) параметров дочернего процесса от родителя (RID, RGID и других атрибутов) жестко регламентированы, достаточно сложны (в зависимости от флагов) и могут быть уточнены в технической документации QNX. Отметим, что безусловно наследуются такие параметры, как: а) приоритет и дисциплина диспетчеризации; б) рабочий и корневой каталоги файловой системы. Не наследуются: установки таймеров процесса
tms_utime
,
tms_stime
,
tms_cutime
и
tms_cstime
, значение взведенного сигнала
SIGALRM
(это значение сбрасывается в ноль), файловые блокировки, блокировки и отображения памяти (shared memory), установленные родителем.
При успешном завершении вызов функции возвращает PID порожденного процесса. При неудаче возвращается -1 и
errno
устанавливается:
•
E2BIG
— количество байт, заданное в списке аргументов или переменных окружения и превышающее
ARG_MAX
;
•
EACCESS
— нет права поиска в каталогах префикса имени файла, или для файла не установлены права на выполнение, или файловая система по указанному пути была смонтирована с флагом
ST_NOEXEC
;
•
EAGAIN
— недостаточно системных ресурсов для порождения процесса;
•
ERADF
— недопустим хотя бы один из файловых дескрипторов в массиве
fd_map
;
•
EFAULT
— недопустима одна из буферных областей, указанных в вызове;
•
ELOOP
— слишком глубокий уровень символических ссылок к файлу или глубина префиксов (каталогов) в полном пути к файлу;
•
EMFILE
— недостаточно ресурсов для отображения файловых дескрипторов в дочерний процесс;
•
ENAMETOOLONG
— длина полного пути превышает
PATH_MAX
или длина компонента имени файла и пути превышает
NAME_MAX
;
•
ENOENT
— файл нулевой длины или несуществующий префиксный компонент в полном пути;
•
ENOEXEC
— файл, указанный как программа, имеет ошибочный для исполняемого файла формат;
•
ENOMEM
— в системе недостаточно свободной памяти для порождения процесса;
•
ENOSYS
— файловая система, специфицированная полным путевым именем файла, не предназначена для выполнения
spawn()
;
•
ENOTDIR
— префиксные компоненты пути исполняемого файла не являются каталогами;
Даже из этого очень краткого обзора вызова
spawn()
становятся очевидными некоторые вещи:
• Эта форма универсальна (самодостаточна), она позволяет обеспечить весь спектр разнообразных форм порождения нового процесса
• Она же и самая громоздкая форма, тяжеловесная для практического кодирования, поэтому в реальных текстах в большинстве случаев вы вместо нее встретите ее конкретизации:
spawnl()
,
spawnle()
,
spawnlp()
,
spawnlpe()
,
spawnp()
,
spawnv()
,
spawnve()
,
spawnvp()
,
spawnvpe()
. Все эти формы достаточно полно описаны в [1]. Функционально они эквивалентны
spawn()
, поэтому мы не станем на них детально останавливаться.
• Хотя вызов
spawn()
и упоминается в описаниях как POSIX-совместимый, в QNX он существенно расширен и модифицирован и поэтому в лучшем случае может квалифицироваться как «выполненный по мотивам» POSIX.
В качестве примера приведем использованную в [4] (глава Д. Алексеева «Утилита on») форму вызова для запуска программы (с именем, заданным в строке
command
) на удаленном узле
node
(например,
/net/xxx
) сети QNET (как вы понимаете, это совершенно уникальная возможность QNX, говорить о которой в рамках POSIX-совместимости просто бессмысленно):
— символьные строки, доступные процессу как список аргументов. Список аргументов должен завершаться значением
NULL
. Аргумент
arg0
должен быть именем файла, ассоциированного с запускаемым процессом.
Примечание
Устоявшаяся терминология «запускаемый процесс» относительно
exec*()
явно неудачна и лишь вводит в заблуждение. Здесь гораздо уместнее говорить о замещении выполнявшегося до этой точки кода новым, выполнение которого начинается с точки входа главного потока замещающего процесса.
Примечание
Если вызов
exec*()
выполняется из многопоточного родительского процесса, то все выполняющиеся потоки этого процесса предварительно завершаются. Никакие функции деструкторов для них не выполняются.
Если вызов
exec*()
успешен, управление никогда уже не возвращается в точку вызова. В случае неудачи возвращается -1 и