Читаем Linux API. Исчерпывающее руководство полностью

Теоретически оба процесса, родительский и дочерний, могут как считывать данные из канала, так и записывать их в него, однако на практике такая ситуация не является типичной. Как правило, сразу же после вызова fork() один из процессов закрывает дескриптор, связанный с записывающим концом канала, а другой делает то же самое для считывающего конца. Например, если родитель собирается передавать данные потомку, он должен закрыть свой дескриптор, предназначенный для чтения (filedes[0]); в то же время потомок должен закрыть дескриптор для записи (filedes[1]). В результате получается ситуация, изображенная в правой части рис. 44.3. Код, реализующий данный пример, показан в листинге 44.1.

Листинг 44.1. Этапы создания канала, подходящего для передачи данных от родителя к потомку

int filedes[2];

if (pipe(filedes) == -1) /* Создаем канал */

errExit("pipe");

switch (fork()) { /* Создаем дочерний процесс */

case -1:

errExit("fork");

case 0: /* Потомок */

if (close(filedes[1]) == -1) /* Закрываем неиспользуемый записывающий конец */

errExit("close");

/* Теперь потомок читает из канала */

break;

default: /* Родитель */

if (close(filedes[0]) == -1) /* Закрываем неиспользуемый считывающий конец */

errExit("close");

/* Теперь родитель записывает в канал */

break;

}

Рис. 44.3.Подготовка канала к передаче данных от родителя к потомку

Родитель и потомок редко сохраняют возможность считывать данные из одного канала, поскольку в этом случае нельзя точно определить, какой из процессов первым выполнит чтение; то есть процессы должны конкурировать за получение информации. Чтобы этого избежать, пришлось бы применять какой-нибудь механизм синхронизации. Но для двунаправленного взаимодействия существует более простой вариант: создать два канала — по одному для передачи данных в каждом направлении (при использовании такой методики следует учитывать возможность взаимных блокировок, когда оба процесса блокируются, пытаясь прочитать из пустых каналов или записать в каналы, которые уже заполнены).

Теоретически в канал можно записывать неограниченное количество процессов, но обычно применяется только один записывающий процесс (пример того, когда может пригодиться несколько таких процессов, будет показан в разделе 44.3). Для сравнения, очередь FIFO допускает ситуации, когда запись из нескольких процессов может быть оправданной (этот случай будет рассмотрен в разделе 44.8).

Каналы обеспечивают взаимодействие родственных процессов

До сих пор мы обсуждали каналы, предназначенные для взаимодействия родительского и дочернего процессов. Однако они дают возможность взаимодействовать любым двум (или более) родственным процессам, общий предок которых создал канал до выполнения цепочки вызовов fork() (вот что мы имели в виду, когда упоминали родственные процессы в начале этой главы). Например, канал позволяет организовать взаимодействие процесса и его внука: сначала процесс открывает канал, затем создает дочерний процесс, который, в свою очередь, создает внука. Обычно каналы используются для взаимодействия родственных процессов одного уровня: родитель открывает канал и создает двух потомков. Именно это и делает командная оболочка, когда формирует конвейер.

Правило, согласно которому каналы могут применяться только для взаимодействия родственных процессов, имеет одно исключение. Сокет домена UNIX позволяет передать файловый дескриптор канала любому процессу (эта методика кратко описана в разделе 57.13.3).

Закрытие неиспользуемых файловых дескрипторов канала

Данное действие требуется не только для того, чтобы не дать процессу превысить ограничение на открытые дескрипторы; это необходимое условие корректной работы каналов. Теперь подумаем, почему неиспользуемые файловые дескрипторы для чтения из канала и записи в него должны быть закрыты.

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

Если читающий процесс не закроет записывающий конец канала, то не сможет узнать, когда другой процесс завершит свой ввод, даже после прочтения всех доступных данных. Вместо этого операция read() будет заблокирована в ожидании новой информации, поскольку ядро знает: у данного канала остался по крайней мере один записывающий дескриптор. Тот факт, что дескриптор открыт самим считывающим процессом, не имеет никакого значения; теоретически этот процесс может записывать в канал, несмотря на то что он заблокирован при попытке чтения. Например, операция read() может быть прервана обработчиком сигнала, который записывает данные в канал (в подразделе 59.5.2 вы увидите реалистичность данного сценария).