Параллельное и распределенное программирование на С++
Шрифт:
Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDULER, и если неу д ачный исхо д функции posix_spawn или posix_spawnp вызван о д ной из причин, которые бы привели к отказу функции sched_setscheduler, возвра щ аемое значение ошибки бу д ет соответствовать описанию для функции sched_setscheduler (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Если аргу м ент file_actions не равен значению NULL и определяет для выполнения любое из действий close, dup2
Примеры
Отсутствуют.
Замечания по использованию
Эти функции являются частью опции Spawn и могут быть не представлены во всех реализациях.
Логическое обоснование
Функция posix_spawn и ее «близкая родственница» функция posix_spawnp были введены для преодоления следующих ощутимых трудностей использования функции fork : функцию fork сложно (или невозможно) реализовать без обмена (подкачки) или динамической трансляции адреса.
• Обмен (механизм подкачки в оперативную память недостающей страницы виртуальной памяти, затребованной программой) — в общем случае слишком медленный механизм для среды реального времени.
• Осуществление динамической трансляции адреса возможно не везде, где может использоваться библиотека POSIX .
• Создание процессов с помощью библиотеки POSIX не требует трансляции адресов или иных услуг, связанных с MMU (memory management unit — блок управления памятью).
Таким образом, библиотека POSIX использует примитивы создания процессов и выполнения файлов, которые могут быть эффективно реализованы без трансляции адресов или иных MMU-процедур.
Функция posix_spawn реализуется как библиотечная программа, но обе функции posix_spawn и posix_spawnp задуманы как операции ядра операционной системы. Несмотря на то что они могут представлять эффективную замену для многих пар функций fork /exec, их цель — обеспечить возможность создания процессов для систем, в которых возникают сложности с применением функции fork , а не полностью вытеснить функции fork / exec.
Такая роль функций 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 возлагается на соответствующее проектирование.
Функции posix_spawn и posix_spawnp не обладают всей полнотой власти, которая характерна для функций fork / exec. И такой эффект вполне ожидаем. Функция fork — чрезвычайно мощная. Мы и не надеялись скопировать все ее возможности в простой и быстрой функции, не предъявляя специальных требований к оборудованию. Важно то, что функции posix_spawn и posix_spawnp очень близки к средствам создания процессов во многих операционных системах, отличных от UNIX.
Требования
К реализации функций posix_spawn и posix_spawnp предъявляются следующие требования.
• Они должны быть реализованы без использования MMU (memory management unit — блок управления памятью) или какого-то иного специального оборудования.
• Они должны быть совместимы с существующими POSIX -стандартами. Дополнительные требования таковы.
• Они должны быть эффективными.
• Их способность по замещению функции fork (в обычных условиях) должна составлять не меньше 50%.
• Система, в которой реализованы функции posix_spawn и posix_spawnp , но не реализована функция fork , должна иметь достаточную эффективность, по крайней мере для приложений реального времени.
• Система, в которой реализована функция fork и семейство функций exec, должна обладать способностью к реализации функций posix_spawn и posix_spawnp как библиотечных программ.
Двухвариантный синтаксис
POSIX-функция exec имеет несколько последовательностей вызовов с приблизительно одинаковой результативностью. Это вызвано практическими реалиями. Поскольку установившаяся практика использования функций posix_spawn существенно отличается от POSIX-варианта, мы посчитали, что простота важнее полной совместимости. Поэтому мы представили только две модификации для функции posix_spawn .
Различий в списках параметров между функциями posix_spawn и posix_spawnp практически нет; при использовании функции posix_spawnp второй параметр интерпретируется более сложно, чем при использовании функции posix_spawn .
Совместимость с POSIX.5 (Ada)
Процедуры Start_Process и Start_Process_Search из пакета привязки языка Ada POSIX_Process_Primitives к POSIX.1 . инкапсулируют действия функций fork и ехес практически так же, как это делают функции posix_spawn и posix_spawnp. Первоначально, придерживаясь цели более простого подхода, разработчики стандарта ограничили возможности функций posix_spawn и posix_spawnp подмножеством возможностей, присущих процедурам Start_Process и Start_Process_Search, отказавшись от поддержки конкретных нестандартных средств. Но на основе пожеланий группы приема стандарта усовершенствовать отображение дескрипторов файлов или совсем отказаться от них, а также по рекомендации членов рабочей группы Ada Language Bindings разработчики стандарта решили, что функции posix_spawn и posix_spawnp должны быть в достаточной степени эффективными для реализации возможностей процедур Start_Process и Start_Process_Search. Мы исходили из того, что если привязка языка Ada к такому базовому варианту уже была одобрена в качестве стандарта IEEE, то вряд ли не будут одобрены эквивалентные части С-привязки. Среди возможностей, реализованных функциями posix_spawn и posix_spawnp, можно насчитать только следующие три пункта, которые не обеспечивались процедурами Start_Process и Start_Process_Search: необязательное задание идентификационного номера группы сыновних процессов, набор сигналов, подлежащих стандартной обработке в сыновнем процессе, а также стратегия планирования (и ее параметры).