Параллельное и распределенное программирование на С++
Шрифт:
Ошибки
Вызовы функций posix_spawn и posix_spawnp могут оказаться неудачными, если:
[EINVAL] значение, за д анное пара м етро м file_actions или пара м етро м attrp, не д ействительно.
Если ошибка возникла после того, как вызывающий процесс успешно вернулся из функции posix_spawn или posix_spawnp , то сыновний процесс может завершиться со стагусом выхода (exit status), равным значению 127.
Если неудачный исход функции posix_spawn или posix_spawnp вызван одной из причин, которые бы привели к отказу функции fork или одной из функций семейства exec, то возвращаемое значение ошибки будет соответствовать описанию для функций fork и exec соответственно (или, если ошибка возникнет после того, как вызывающий процесс успешно вернется, сыновний процесс завершится со статусом выхода, равным значению 127).
Если в атрибуте spawn-flags
PS Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDPARAM, а флаг POSIX_SPAWN_SETSCHEDULER не установлен, то, если неу д ачный исхо д функции posix_spawn или posix_spawnp вызван о д ной из причин, которые бы привели к отказу функции sched_setparam, возвра щ ае м ое значение ошибки бу д ет соответствовать описанию д ля функции sched_setparam (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхо д а, равны м значению 127).
Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDULER, и если неу д ачный исхо д функции posix_spawn или posix_spawnp вызван о д ной из причин, которые бы привели к отказу функции sched_setscheduler, возвра щ аемое значение ошибки бу д ет соответствовать описанию для функции sched_setscheduler (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Если аргу м ент file_actions не равен значению NULL и определяет для выполнения любое из действий close, dup2 или орел, и если неудачный исход функции posix_spawn или posix_spawnp вызван одной из причин, которые бы привели к отказу функций close, dup2 или open, возвра щ ае м ое значение ошибки будет соответствовать описанию для функций close , dup2 и open соответственно (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Действие, связанное с открытие м файла, м ожет са м о по себе выразиться в любой из ошибок, описанных для функций close или dup2 , по м и м о тех, что описаны для функции open .
Примеры
Отсутствуют.
Замечания по использованию
Эти функции являются частью опции Spawn и могут быть не представлены во всех реализациях.
Логическое обоснование
Функция posix_spawn и ее «близкая родственница» функция posix_spawnp были введены для преодоления следующих ощутимых трудностей использования функции fork : функцию fork сложно (или невозможно) реализовать без обмена (подкачки) или динамической трансляции адреса.
• Обмен (механизм подкачки в оперативную память недостающей страницы виртуальной памяти, затребованной программой) — в общем случае слишком медленный механизм для среды реального времени.
• Осуществление динамической трансляции адреса возможно не везде, где может использоваться библиотека POSIX .
• Создание процессов с помощью библиотеки POSIX не требует трансляции адресов или иных услуг, связанных с MMU (memory management unit — блок управления памятью).
Таким образом, библиотека POSIX использует примитивы создания процессов и выполнения файлов, которые могут быть эффективно реализованы без трансляции адресов или иных MMU-процедур.
Функция posix_spawn
Такая роль функций posix_spawn и posix_spawnp оказала влияние на их API-интерфейс. Здесь не было попытки обеспечить полную функциональность пар fork/exec, при использовании которых между созданием сыновнего процесса и выпол н ение м образа нового процесса разрешаются любые определенные пользователе м операции; ведь Любая попытка достичь такого уровня потребовала бы пара м етрического задания используе м ого языка програ мм ирования. Поэто м у функции posix_spawn и posix_spawnp представляют собой базовые операции создания процессов, подобные процедура м Start_Process и Start_Process_Search из пакета POSIX_Process_Primitives в языке программирования Ada, а также другим операциям, предусмотренным во многих операционных системах (но не UNIX), оснащенных POSIX -расширениями.
Функции posix_spawn и posix_spawnp обеспечивают управление шестью типами наследования: файловыми дескрипторами, идентификационным номером (ID) группы процессов, ID пользователя и группы, маской сигналов, стратегией планирования, а также управление сигналами (будет ли каждый сигнал, игнорируемый в родительском процессе, игнорироваться и в сыновнем, или же он будет установлен равным действию по умолчанию).
Возможность управления файловыми дескрипторами позволяет независимо записанному образу сыновнего процесса получить доступ к потокам данных, открытым (или даже сгенерированным) либо читаемым родительским процессом, без специального программирования средств, с помощью которых можно было бы определить, какие файлы (файловые дескрипторы) используются в родительском процессе. Возможность управления идентификационным номером группы процессов позволяет установить, как механизм управления заданиями в сыновнем процессе связан с аналогичным механизмом в родительском процессе.
Управления маской сигналов и установкой сигналов по умолчанию вполне достаточно для поддержки реализации функции system. Несмотря на то что поддержка функции system не является одной из явных целей для функций posix_spawn и posix_spawnp , все же эта поддержка составляет не менее 50% от общей «суммы целей».
Намерение состоит в том, что обычное насле д ование файлового д ескриптора через функцию fork , последующий результат за д анных д ействий над файлами и обычное наследование файлового дескриптора через одну из функций семейства exec должно полностью определять наследование открытых файлов. Реализации не нужно принимать никаких решений относительно набора открытых дескрипторов файлов в начале выполнения образа сыновнего процесса, эти решения уже были приняты инициатором вызова функции и выражены в виде набора открытых д ескрипторов файлов и их флагов FD_CLOEXEC в м о м ент вызова, а также объекта действий над файлами, заданного в этом вызове. Мы убеждены, что в случаях, когда POSIX -примитивы языкa Ada (Start_Process) реализованы в библиотеке, этот метод управления наследованием файловых дескрипторов может быть реализован очень легко.
Мы м оже м и д ентифицировать ря д пробле м, связанных с использование м функций posix_spawn( ) и posix_spawnp , но на м неизвестно решение с м еньши м количество м пробле м. Мо д ификация сре д ы д ля атрибутов сыновнего процесса, которая не определяется с по м о щ ью аргу м ентов attrp или file_actions, д олжна быть выполнена в ро д ительско м процессе, а поскольку ро д ительский процесс обычно стремится сохранить свой контекст, это более затратно, чем аналогичное поведение, достигаемое с помощью функций fork /exec. Кроме того, сложно модифицировать на время среду многопоточного процесса, поскольку для безопасного изменения среды все потоки должны быть согласованы. Однако на эти затраты еще можно было бы пойти, применяя вызовы тех функций posix_spawn и posix_spawnp , которые используют дополнительные возможности. А поскольку расширенные модификации— это исключение, а не правило, и они особенно непригодны в критическом ко времени выполнения коде, сохранение большинства «рычагов управления» средой вне функций posix_spawn и posix_spawnp возлагается на соответствующее проектирование.