Управления маской сигналов и установкой сигналов по умолчанию вполне достаточно для поддержки реализации функции 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.