*CLOEXEC об

[Valentin Nechayev]

Читаю очередной ман и вижу:

===
MSG_CMSG_CLOEXEC (recvmsg() only; since Linux 2.6.23)
Set the close-on-exec flag for the file descriptor received via
a UNIX domain file descriptor using the SCM_RIGHTS operation
(described in unix(7)). This flag is useful for the same rea-
sons as the O_CLOEXEC flag of open(2).
===

Вам не кажется, что вместо придумывания кучи подобных флагов для
каждого интерфейса отдельно, было бы проще сделать вообще глобальный
флаг на уровне всего процесса - "все новосоздаваемые дескрипторы
автоматически получают FD_CLOEXEC"? А кто не хочет такого - пусть явно
снимает у совершенно конкретных дескрипторов.

Да, придётся подпилить все библиотеки, которые делают fork(), но таких
не так уж много, и за несколько лет этот процесс прошёл бы
беспроблемно.


--netch--

[Serguei E. Leontiev]

Валентин, привет,

Post by Valentin Nechayev
===
MSG_CMSG_CLOEXEC (recvmsg() only; since Linux 2.6.23)

Сборник предложенных дополнений к следующей версии POSIX в этой области:

http://www.austingroupbugs.net/view.php?id=368

http://www.austingroupbugs.net/view.php?id=411

Post by Valentin Nechayev
Вам не кажется, что вместо придумывания кучи подобных флагов для
каждого интерфейса отдельно, было бы проще сделать вообще глобальный
флаг на уровне всего процесса - "все новосоздаваемые дескрипторы
автоматически получают FD_CLOEXEC"? А кто не хочет такого - пусть явно
снимает у совершенно конкретных дескрипторов.

Лично мне так не кажется, IMHO проще не станет. Поясню, если я пишу
библиотеку, то я не смогу использовать предложенный глобальный флаг
процесса, т.к. я не буду иметь возможности его установить, таким образом
мне всё равно будут нужны дополнения 0000411.

Мало того, простым флагом потока для этой цели тоже нельзя будет
воспользоваться, т.к. обработчики сигналов могут использовать
open()/accept()/...

Таким образом, такого рода флаг потока должен иметь существенно более
сложное определение.

Hо это не всё, есть засада номер 2. Как после введения этого флага будет
звучать описание open()?

Конечно, для реализации дополнения 0000368, этот "хитрый" флаг потока может
оказаться интересным. Hо ещё один нелокальный объект POSIX (в дополнение к
locale, маске сигналов, и др.), радости тоже не прибавит.

[Valentin Nechayev]

SEL> Сборник предложенных дополнений к следующей версии POSIX в этой области:
SEL> http://www.austingroupbugs.net/view.php?id=368
SEL> http://www.austingroupbugs.net/view.php?id=411

Слишком половинчато.

[...]

SEL> Hо это не всё, есть засада номер 2. Как после введения этого флага будет
SEL> звучать описание open()?

Точно так же, как сейчас, с поправкой на то, что у fd_flags&FD_CLOEXEC
стартовое значение - не 0, а копируется из этого глобального флага.

С моей точки зрения, засада не в этом, а в том, как сделать, чтобы
после перехода дать старое поведение старому коду. Вот тут помогло бы,
например, мапить open() и прочие стандартные имена в разные реальные
вызовы в зависимости от POSIX_C_SOURCE и аналогов.

SEL> Конечно, для реализации дополнения 0000368, этот "хитрый" флаг потока может
SEL> оказаться интересным. Hо ещё один нелокальный объект POSIX (в дополнение к
SEL> locale, маске сигналов, и др.), радости тоже не прибавит.

Решается, я ж говорю, тривиально. Hа переходный период всем
дескрипторам, которые должны передаваться сквозь exec(), потребуется
дописать явный сброс этого флага. Более серьёзные проблемы см. выше.


--netch--

[Serguei E. Leontiev]

Валентин привет,

Post by Valentin Nechayev

Post by Serguei E. Leontiev
http://www.austingroupbugs.net/view.php?id=368
http://www.austingroupbugs.net/view.php?id=411

Слишком половинчато.

[0] Зато без глобального объекта.

Post by Valentin Nechayev

Post by Serguei E. Leontiev
Hо это не всё, есть засада номер 2. Как после введения этого флага будет
звучать описание open()?

Точно так же, как сейчас, с поправкой на то, что у fd_flags&FD_CLOEXEC
стартовое значение - не 0, а копируется из этого глобального флага.

Так, увы не пройдёт, т.к. на open() ссылаются другие части POSIX, например,
dbm_open(), posix_spawn_file_actions_addopen(). Заметим, что в этих местах
вызов fcntl() после операции открытия невозможен.

Да и лишний системный вызов не радует. Таким образом получаем вариант:

[1] Флаг потока.

а. Определяем, дополнительно к 0000411, флаги *_NOCLOEXEC для всех
перечисленных в это предложении мест;
б. Вводим функцию изменения/восстановления флага;
г. Корректируем описание функций signal() и sigaction();

Post by Valentin Nechayev
С моей точки зрения, засада не в этом, а в том, как сделать, чтобы
после перехода дать старое поведение старому коду. Вот тут помогло бы,
например, мапить open() и прочие стандартные имена в разные реальные
вызовы в зависимости от POSIX_C_SOURCE и аналогов.

М-м, ну это надо только для "экстремального" варианта:

[2] Безусловное использование *_CLOEXEC.

а. Определяем флаг O_NOCLOEXEC для open();
б. Для всех мест, перечисленных в 0000411, описываем новый функционал.
г. Быть может, потребуются новые флаги, может нет, но при реализации
внутренние флаги *_NOCLOEXEC потребуются.

Post by Valentin Nechayev

Post by Serguei E. Leontiev
Конечно, для реализации дополнения 0000368, этот "хитрый" флаг потока может
оказаться интересным. Hо ещё один нелокальный объект POSIX (в дополнение к
locale, маске сигналов, и др.), радости тоже не прибавит.

Решается, я ж говорю, тривиально. Hа переходный период всем
дескрипторам, которые должны передаваться сквозь exec(), потребуется
дописать явный сброс этого флага. Более серьёзные проблемы см. выше.

Первоначально предложенный вариант с флагом процесса неработоспособен.

Вариант [1] потребует при написании библиотек постоянно взводить/опускать
флаг.

Вариант [2] подразумевает существенную зависимость от POSIX_C_SOURCE,
которой на настоящий момент нет.

В общем вариант [0] вводит меньше новых сущностей и требует меньшей
документации.

Хотя, лично я бы предпочёл определить функции exec*() и
posix_spawn_file_actions_addclose(), как отмеченные к удалению, и
рекомендовал бы использовать только posix_spawn*() с новым атрибутом
"закрыть всё".

[Valentin Nechayev]

VN> Вам не кажется, что вместо придумывания кучи подобных флагов для
VN> каждого интерфейса отдельно, было бы проще сделать вообще глобальный
VN> флаг на уровне всего процесса - "все новосоздаваемые дескрипторы
VN> автоматически получают FD_CLOEXEC"? А кто не хочет такого - пусть явно
VN> снимает у совершенно конкретных дескрипторов.

Вот вчера и наступили в полный размах именно на эту проблему.
Чтение из пайпа убитого процесса не прекращается потому, что пишущий
конец пайпа случайно достался соседнему аналогичному процессу.
Теперь судорожно рисую обёртку мьютексом вокруг цикла pipe() - popen()
- close() на лишнее (ну, на python, но суть та же).

VN> Да, придётся подпилить все библиотеки, которые делают fork(), но таких
VN> не так уж много, и за несколько лет этот процесс прошёл бы
VN> беспроблемно.

Или на уровне треда это сделать, но универсально для старого кода.


--netch--