posix_spawn_file_actions_addclose, posix_spawn_file_actions_addopen

Имя

posix_spawn_file_actions_addclose, posix_spawn_file_actions_addopen— функции внесения в объект действий над файла м и действия «закрыть файл» (или «открыть файл») (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix__spawn_file_actions_addclose (

posix_spawn_file_actions_t *file_actions, int fildes); int posix_spawn_file_actions_addopen (

posix_spawn_file_actions_t *restrict file_actions, int fildes,

const char *restrict path, int oflag, mode_t mode) ;

Описание

Эти функции добавляют в объект действий над файла м и действие «закрыть файл» (или «открыть файл») или удаляют соответствую щ ее действие из это г о объекта.

Объект действий над файла м и и м еет тип posix_spawn_file_actions_t (который определен в за г оловке <spawn.h>) и используется для задания последовательности действий, подлежа щ их выполнению функция м и posix_spawn() или posix_spawnp() с целью получения для сыновне г о процесса м ножества открытых файловых дескрипторов в соответствии с м ножество м открытых файловых дескрипторов родительско г о процесса. Стандарт IEEE Std 1003.1-2001 не определяет для типа posix_spawn_file_actions_t операторы сравнения или присваивания.

Объект действий над файлами, передаваемый функции posix_spawn() или posix_spawnp (), определяет, как множество открытых файловых дескрипторов вызывающего процесса должно быть трансформировано во множество потенциально открытых файловых дескрипторов для порождаемого процесса. Эта трансформация должна выглядеть так, как если бы однократно была выполнена заданнал последовательность действий в контексте порожденного процесса (до выполнения образа нового процесса), причем в порядке, в котором эти действия были добавлены в объект. Кроме того, при выполнении образа нового процесса любой файловый дескриптор (из этого нового множества), у которого установлен флаг FD_CLOEXEC, должен быть закрыт (см. описание функции posix_spawn ()).

Функция posix_spawn_file_actions_addclose() добавляет в объект, адресуемый параметром file_actions, действие по закрытию файлов close, в результате чего при порождении нового процесса с использованием объекта действий файловый дескриптор, заданный параметром fildes, будет закрыт (как если бы была вызвана функция close (fildes)).

Функция posix_spawn_file_actions_addopen () добавляет в объект, адресуемый параметром file_actions, действие по открытию файлов орел, в результате чего при порождении ново г о процесса с использование м объекта действий файл, и м я которо г о зада н о пара м етро м path, будет открыт (как если бы была вызва н а функция open (path, oflag, mode) , и возвра щ енно м у ею файлово м у дескриптору, если он не равен значению fildes, будет присвоено значение fildes). Если дескриптор fildes относится к уже открыто м)' файлу, этот файл будет закрыт перед открытие м нового файла.

Строка, адресуе м ая пара м етро м path, копируется функцией posix_spawn_file_actions_addopen().

Возвращаемые значения

При успешном завершении эти функции возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Эти функции завершатся неудачно, если:

[EBADF] значение, заданное пара м етро м fildes, отрицательно либо больше или равно значению {OPEN_MAX}.

Выполнение этих функций м ожет завершиться неудачно, если: [EINVAL] значение, заданное пара м етро м file_actions, недопусти м о;

[ENOMEM] для расширения содержи м ого объекта действий над файлами недостаточно су щ ествую щ ей па м яти.

Не считается ошибкой, если в качестве значения аргу м ента fildes, передавае м ого эти м функция м, указа н файловый дескриптор, дл я которого задан н ал операция не м ожет быть выполнена во вре м я вызова. Любая подобнал ошибка будет обнаружена, когда соответствую щ ий объект действий над фай л а м и позже будет испо л ьзован при выпо л нении функции posix_spawn () и л и posix_spawnp ().

Примеры

Отсутствуют.

Замечания по использованию

Эти функции яв л яются частью опции Spawn и м огут быть не представ л ены во всех реализациях.

Логическое обоснование

Объект действий над фай л а м и м ожно инициализировать с по м о щ ью упорядоченной пос л едовате л ьности операций close (), dup2 () и open (), предназначенной д л я испо л ьзования функция м и posix_spawn () и л и posix_spawnp () с це л ью получения м ножества открытых фай л овых дескрипторов, унас л едованных порожденны м процессо м от своего родите л я, и м ею щ е г о собственное м ножество открытых фай л овых дескрипторов в м о м ент вызова функции posix_spawn () и л и posix_spawnp (). Д л я реор г анизации фай л овых дескрипторов бы л о пред л ожено о г раничиться то л ько операция м и close () и dup2 (), а для то г о, чтобы порожденный процесс получил «в наследство» открытые файлы, м ожно посгупить дву м я способа м и: либо заставить вызывающий процесс открывать их перед вызово м функции posix_spawn() или posix_spawnp() (и закрывать их пото м), либо передавать и м ена нужных файлов в порожденный процесс (в аргу м енте argv), чтобы он м ог их открыть са м остоятельно. Разработчики стандарта реко м ендовали использовать на практике один из этих двух способов, поскольку детализированный статус ошибки в случае сбоя при выполнении операции открытия файла всегда доступен для приложения. Но разработчики стандарта по следую щ и м причина м все же считают воз м ожны м разрешить включение в объект действий над файла м и операцию open.

1. Это согласуется с эквивалентной функциональностью библиотеки POSIX .5 (Ada).

2. Это поддерживает парадигму перенаправления потоков ввода-вывода, часто применяемую POSIX-программами, предназначенными для вызова из оболочки. Если такая программа является сыновним процессом, ее можно сориентировать на самостоятельное открытие файлов.

3. Это позволяет сыновнему процессу открывать файлы, которые не должен открывать родительский процесс, поскольку операция по открытию файлов в этом случае может оказаться неудачной или нарушить права доступа к файлам (или права собственности).

Относительно приведенного выше п. 2 заметим, что действие «открыть файл» создает для функций posix_spawn () и posix_spawnp () те же возможности, что и операторы перенаправления для функции system(), но только без промежуточного выполнения оболочки. Например, так: system («myprog <filel 3<file2»);

Относительно приведенного выше п. 3 заметим, что если вызывающему процессу нужно открыть один или несколько файлов для доступа к ним порожденного процесса, но он обладает недостаточными запасами файловых дескрипторов, то выполнение действия open () необходимо позволить в контексте сыновнего процесса после того, как другие файловые дескрипторы (которые должны оставаться открытыми в родительском процессе) будут закрыты.

Кроме того, если родительский процесс выполняется из файла, для которого установлен бит режима «set-user-id» (идентификационный номер пользователя установлен) и в атрибутах порожденного процесса установлен флаг POSIX_SPAWN_RESETIDS, то файл, созданный в родительско м процессе, получит (воз м ожно, некорректно) в качестве владельца родительский ID эффективного пользователя, в то вре м я как файл, созданный действие м open() при выполнении функции posix_spawn() или posix_spawnp(), получит в качестве владельца реальный ID родительского процесса; при это м операция open, выполненнал родительски м процессо м, м ожет успешно открыть файл, к которо м у реальный пользователь не должен и м еть доступ, или неудачно открыть (т.е. не открыть) файл, к которо м у реальный пользователь должен и м еть доступ.

Преобразование файловых дескрипторов

Разработчики стандарта первоначально предлагали использовать массив, который бы определял преобразование файловых дескрипторов сыновнего процесса в обратном направлении, т.е. при переходе к родительскому процессу. Группа приема стандарта обратила внимание на то, что невозможно произвольно перетасовывать файловые дескрипторы в библиотечной реализации функции posix_spawn() или posix_spawnp (), не имея запаса файловых дескрипторов (которого попросту может не быть). Такой массив требует, чтобы реализация обладала сложной стратегией достижения нужного преобразования, которая бы исключала случайное закрытие «не того» файлового дескриптора в самое неподходящее время.

Одним из членов рабочей группы Ada Language Bindings было отмечено, что принятое в языке Ada семейство POSIX-примитивов Start_Process использует м ножество действий (задавае м ое инициаторо м вызова функции), чтобы изменить общепринятую семантику функций fork () /exec с целью наследования файловых дескрипторов довольно гибким способом, и пока никаких проблем не возникало, поскольку все бремя определения, как достичь конечного преобразования файловых дескрипторов, полностью лежит на приложении. Более того, хотя интерфейс, связанный с действиями над файлами, выглядит устрашающе сложным, в действительности он довольно прост для реализации либо в библиотеке, либо в ядре.

Будущие направления

Отсутствуют.

Смотри также

close (), dup (), open (), posix_spawn (), posix_spawn_file_actions_adddup2 (),

posix_spawn_file_actions_destroy (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, < spawn. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1d-1999.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #105, со г ласно которой в раздел «Описание» было внесено дополнение о то м, что строка, адресуе м ал пара м етро м path, копируется функцией posix_spawn_file_actions_addopen ().