QNX/UNIX: Анатомия параллелизма
вернуться

Цилюрик Олег Иванович
Шрифт:
Примечание

Если дочерний процесс является скриптом интерпретатора (флаг

SPAWN_CHECK_SCRIPT
), то первая строка текста скрипта должна начинаться с
#!
, за которыми должны следовать путь и аргументы того интерпретатора, который будет использоваться для интерпретации этого скрипта. К скрипту не применяется установленный в системе интерпретатор по умолчанию (как это происходит при вызове его по имени из командной строки).

Правила наследования (и ненаследования) параметров дочернего процесса от родителя (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-совместимости просто бессмысленно):

int main {

char* command = "...", *node = "...";

// параметры запуска не используются

char* const argv[] = { NULL };

struct inheritance inh;

inh.flags = 0;

// флаг удаленного запуска

inh.flags |= SPAWN_SETND;

// дескриптор хоста

inh.nd = netmgr_strtond(node, NULL);

pid_t pid = spawnp(command, 0, NULL, &inh, argv, NULL);

...

}

Использованная здесь форма

spawnp
наиболее близка к базовой
spawn
и отличается лишь тем, что для поиска файла программы используется переменная системного окружения
PATH
.

Приведем характерный пример вызова группы

exec*
:

int execl(const char* path, const char* arg0, const char* arg1, ...