posix_spawn_file_actions_addclose()

Добавить или удалить в объект действий над файлами действия «закрыть файл»

Прототип:

#include <posix_spawn_file_actions.h>
int posix_spawn_file_actions_addclose( posix_spawn_file_actions_t *fact_p,
int fd );

Аргументы:

fact_p
Действие файла для добавления или удаления в объекте действий файла порожденного процесса.
fd
Количество дескрипторов файлов в массиве.

Библиотека:

libc

Описание:

Эта функция добавляет или удаляет действие close() или open() в объект действий файла порожденного процесса. Объект действий файла порожденного процесса имеет тип 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() добавляет действие close() к объекту, на который ссылается fact_p, что приводит к закрытию файлового дескриптора fd (как если бы он вызывал close( fd )) при порождении нового процесса, используя этот объект файловых действий.

Объект действий файла порожденного процесса может быть инициализирован, чтобы содержать упорядоченную последовательность операций 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. Данный метод позволяет открывать файлы, которые в противном случае могли бы завершиться ошибкой или нарушить права владения/доступа к файлу, если бы они выполнялись родительским процессом.

Важно отметить, что действие открытия файла порождения предоставляет posix_spawn() и posix_spawnp() те же возможности, которые операторы перенаправления оболочки предоставляют system(), только не вмешиваясь в выполнение оболочки; Например:

system( "myprog <file1 3<file2" );

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

Сопоставление файловых дескрипторов. Изначально разработчиками стандарта предлагалось использовать массив, определяющий сопоставление дочерних файловых дескрипторов с дескрипторами родительского. Далее стало понятно, что невозможно произвольно перетасовать файловые дескрипторы в библиотечной реализации posix_spawn() или posix_spawnp() без предоставления одной или нескольких запасных записей файловых дескрипторов (которые могут быть недоступны). Такой массив требует, чтобы реализация разработала сложную стратегию для достижения желаемого сопоставления без непреднамеренного закрытия неправильного файлового дескриптора в неподходящее время. Член рабочей группы Ada Language Bindings отметил, что утвержденное семейство Ada Language Start_Process примитивов процесса POSIX использует указанный вызывающей стороной набор файловых действий для изменения обычной семантики fork/exec для наследования файловых дескрипторов в очень гибкой форме. Таким образом, таких проблем не существует, потому что бремя определения того, как добиться окончательного сопоставления дескриптора файла, полностью лежит на приложении. Кроме того, хотя интерфейс действий с файлами на первый взгляд кажется пугающим, на самом деле его довольно просто реализовать как в библиотеке, так и в ядре.

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

EBADF
Значение, указанное в fd, отрицательное или больше или равно {OPEN_MAX}.
EINVAL
Был задан недопустимый параметр или значение, указанное в fact_p, является недопустимым.
ENOMEM
Если действие не может быть добавлено к объекту действий с файлом или недостаточно памяти для добавления к объекту действий файла порожденного процесса. Не считается ошибкой, если аргумент fd, переданный этим функциям, указывает файловый дескриптор, для которого указанная операция не могла быть выполнена во время вызова. Любая такая ошибка будет обнаружена, когда связанный с файлом объект действий будет позже использован во время операции posix_spawn() или posix_spawnp().
EOK
Успешное завершение.

Классификация:

POSIX 1003.1 RTS

Точка остановки потока
Нет
Обработчик прерываний
Да
Обработчик сигналов
Да
В потоке
Да

Тематические ссылки:

close(), dup2(), open(), posix_spawn(), posix_spawnp(), posix_spawn_file_actions_adddup2(), posix_spawn_file_actions_addopen(), posix_spawn_file_actions_destroy(), posix_spawn_file_actions_init(), posix_spawnattr_addpartid(), posix_spawnattr_addpartition(), posix_spawnattr_destroy(), posix_spawnattr_getcred(), posix_spawnattr_getflags(), posix_spawnattr_getnode(), posix_spawnattr_getpartid(), posix_spawnattr_getpgroup(), posix_spawnattr_getrunmask(), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigdefault(), posix_spawnattr_getsigignore(), posix_spawnattr_getsigmask(), posix_spawnattr_getstackmax(), posix_spawnattr_getxflags(), posix_spawnattr_init(), posix_spawnattr_setcred(), posix_spawnattr_setflags(), posix_spawnattr_setnode(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedparam(), posix_spawnattr_setrunmask(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigdefault(), posix_spawnattr_setsigignore(), posix_spawnattr_setsigmask(), posix_spawnattr_setstackmax(), posix_spawnattr_setxflags(), system()




Предыдущий раздел: Описание API системной библиотеки