Параллельное и распределенное программирование на С++

Такая роль функций 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 — блок управления памятью) или какого-то иного специального оборудования.