Linux API. Исчерпывающее руководство

При взгляде на рис. 44.1 можно обратить внимание на способ подключения процессов к каналу: тот, что записывает данные (ls), соединяет свой стандартный вывод (файловый дескриптор 1 — fd 1) с записывающим концом канала, а считывающий процесс (wc) подключает свой стандартный ввод (файловый дескриптор 0 — fd 0) к его другому концу, предназначенному для чтения. Как следствие, ни один из процессов не знает о существовании канала; они просто используют стандартные файловые дескрипторы для чтения и записи. Командная оболочка должна проделать некоторую работу, чтобы наладить такое взаимодействие; в разделе 44.4 объясняется, как это происходит.

В следующих подразделах будет рассмотрен целый ряд важных особенностей, присущих каналам.

Канал — это поток байтов

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

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

Чтение из канала

Любая попытка прочитать данные из пустого канала блокируется до тех пор, пока кто-нибудь не запишет в этот канал хотя бы один байт. Если закрыть другой конец канала, процесс, выполняющий чтение, получит конец файла (то есть операция read() вернет 0), как только дочитает оставшиеся данные.

Каналы являются однонаправленными

Данные внутри канала могут перемещаться только в одном направлении. Один конец канала используется для записи, а другой — для чтения.

В ряде других реализаций UNIX (в частности, тех, что происходят от четвертой редакции System V) каналы являются двунаправленными (так называемые потоковые каналы). Они не описаны ни в одном стандарте, связанном с UNIX, поэтому даже в системах, в которых они поддерживаются, на их семантику лучше не полагаться. В качестве альтернативы можно применять парные потоковые сокеты доменов UNIX (создаются с помощью вызова socketpair(), описанного в разделе 53.5), предоставляющие стандартизированный двунаправленный механизм взаимодействия, семантически эквивалентный потоковым каналам.

Запись данных, чей объем не превышает PIPE_BUF байт, является гарантированно атомарной

Если несколько процессов выполняют запись в один и тот же канал, их данные никогда не перемешаются, если ни один из них не станет записывать более чем PIPE_BUF байт за раз.

Стандарт SUSv3 требует, чтобы значение PIPE_BUF было не менее _POSIX_PIPE_BUF (512). Система должна определить PIPE_BUF (внутри ) и/или позволить вызову fpathconf(fd, _PC_PIPE_BUF) возвращать действующее ограничение на максимальный размер атомарной записи. Значение PIPE_BUF варьируется в зависимости от системы — например, в FreeBSD 6.0 оно равно 512 байт, в Tru64 5.1 — 4096 байт, а в Solaris 8 — 5120 байт. В Linux PIPE_BUF имеет значение 4096.

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