Posix_spawn и нестандартная настройка канала для ipc между родительским и дочерним процессами
Файловые действия posix_spawn описывают код установки для дочернего процесса, прежде чем он сможет запустить execve (который удаляет стек и т. д.).
Предполагаемый вариант использования состоит в том, чтобы иметь один или несколько дополнительных каналов от дочернего процесса к родительскому процессу в качестве отдельного канала, который потенциально не может быть загрязнен журналами stderr или stdout дочерним процессом.
Пользовательский код в дочернем процессе должен иметь возможность использовать отдельные дескрипторы каналов в качестве выделенных каналов связи с родительским процессом, даже при exec (и не только при выполнении функций).
Мы хотим закрыть один конец канала, чтобы предотвратить неограниченное чтение, ожидающее ввода, и, следовательно, должны dup() его без предоставления дескриптора файла, потому что любой выбранный дескриптор файла может использоваться для других операций между родителем и дочерним элементом (без CLOEXEC и co set).
Насколько я понимаю, это оставляет только 2 варианта при настройке дочернего процесса (после клонирования до execve):
- хранить переменные среды во время настройки дочернего процесса
- добавить файловые дескрипторы в свой собственный стандартный ввод для последующего анализа/использования в пользовательском коде
Определяет ли posix_spawn действия для 1. изменения переменных среды или 2. применения операций записи во время установки дочернего процесса? Если ответ на оба вопроса отрицательный: Есть ли портативный способ обойти проблему, например, с помощью указателей на функции? Видите ли вы какие-либо ошибочные предположения или обходные пути, как упростить решение?
Ответы 1
posix_spawnпринимает в качестве аргумента указатель на желаемую дочернюю среду. Если вы хотите использовать родительскую среду, вы можете просто передатьenvironздесь, но это не обязательно. Если вы хотите передать его измененную версию, вы должны создать ее в родительском объекте перед вызовомposix_spawnи передать указатель на нее.Не существует такой вещи, как «добавление файловых дескрипторов в стандартный ввод», независимо от того, используете ли вы
posix_spawnили какие-либо другие механизмы. stdin — это один дескриптор файла (0), который ссылается на описание одного открытого файла. Я не понимаю, чего именно вы пытаетесь достичь, но обычный шаблон использования заключается в том, что вы настраиваете канал в родительском элементе, а затем используете действия с файлом dup2 (передается как аргументposix_spawn), чтобы поместить конец чтения этот канал на дочернем fd 0. Затем конец записи может быть записан из родителя или передан одному или нескольким другим процессам, чтобы они могли писать в него.
Идея состояла в том, чтобы сохранить кучу dup() и close(), но я понимаю компромисс дизайна, чтобы сделать настройку дочернего процесса простой и не позволить пользователям ее испортить.