• Она же и самая громоздкая форма, тяжеловесная для практического кодирования, поэтому в реальных текстах в большинстве случаев вы вместо нее встретите ее конкретизации: 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, ...
const char* argn, NULL);
где path
— путевое имя исполняемого файла; arg0
, …, argn
— символьные строки, доступные процессу как список аргументов. Список аргументов должен завершаться значением NULL
. Аргумент arg0
должен быть именем файла, ассоциированного с запускаемым процессом.
Устоявшаяся терминология «запускаемый процесс» относительно exec*()
явно неудачна и лишь вводит в заблуждение. Здесь гораздо уместнее говорить о замещении выполнявшегося до этой точки кода новым, выполнение которого начинается с точки входа главного потока замещающего процесса.
Если вызов exec*()
выполняется из многопоточного родительского процесса, то все выполняющиеся потоки этого процесса предварительно завершаются. Никакие функции деструкторов для них не выполняются.
Если вызов exec*()
успешен, управление никогда уже не возвращается в точку вызова. В случае неудачи возвращается -1 и errno
устанавливается так же, как описано выше для spawn()
.
В качестве примера работы вызова spawn*()
(использование exec()
аналогично) рассмотрим приложение (
• Родительский процесс (SIGUSR1
(сигналы детально обсуждаются позже, но здесь попутно «вскроем» одну из их особенностей).
• Дочерний процесс периодически посылает родителю сигнал SIGUSR1
.
• Родительский процесс может переустановить (с помощью параметров командной строки запуска) для дочернего: период посылки сигнала (1-й параметр задан в нашем приложении константой) и приоритет, с которым будет выполняться дочерний процесс (2-й параметр, в качестве которого ретранслируется единственный параметр команды запуска родителя).