При взгляде на рис. 44.1 можно обратить внимание на способ подключения процессов к каналу: тот, что записывает данные (ls), соединяет свой стандартный вывод (файловый дескриптор 1 — fd 1) с записывающим концом канала, а считывающий процесс (wc) подключает свой стандартный ввод (файловый дескриптор 0 — fd 0) к его другому концу, предназначенному для чтения. Как следствие, ни один из процессов не знает о существовании канала; они просто используют стандартные файловые дескрипторы для чтения и записи. Командная оболочка должна проделать некоторую работу, чтобы наладить такое взаимодействие; в разделе 44.4 объясняется, как это происходит.
В следующих подразделах будет рассмотрен целый ряд важных особенностей, присущих каналам.
Когда мы говорим, что канал представляет собой поток байтов, мы имеем в виду следующее: при его использовании не существует понятия сообщений или их границ. Процесс, считывающий данные из канала, может прочитать блок любого размера, независимо от того, насколько большой блок был туда записан другим процессом. Кроме того, данные проходят через канал последовательно — байты считываются из него в том же порядке, в котором они были записаны. Произвольный доступ к содержимому канала с помощью вызова lseek() невозможен.
Реализацию принципа отдельных сообщений в канале следует делать на уровне приложения. Это вполне выполнимая задача (см. раздел 44.8), но для подобных целей лучше применять другие IPC-механизмы, такие как очереди сообщений и датаграммные сокеты (мы рассмотрим их в следующих главах).
Любая попытка прочитать данные из пустого канала блокируется до тех пор, пока кто-нибудь не запишет в этот канал хотя бы один байт. Если закрыть другой конец канала, процесс, выполняющий чтение, получит конец файла (то есть операция read() вернет 0), как только дочитает оставшиеся данные.
Данные внутри канала могут перемещаться только в одном направлении. Один конец канала используется для записи, а другой — для чтения.
В ряде других реализаций UNIX (в частности, тех, что происходят от четвертой редакции System V) каналы являются двунаправленными (так называемые
Если несколько процессов выполняют запись в один и тот же канал, их данные никогда не перемешаются, если ни один из них не станет записывать более чем PIPE_BUF байт за раз.
Стандарт SUSv3 требует, чтобы значение PIPE_BUF было не менее _POSIX_PIPE_BUF (512). Система должна определить PIPE_BUF (внутри
Если записываемый в канал блок данных превышает PIPE_BUF байт, ядро может разбить его на более мелкие части и передавать их по мере того, как считывающий процесс удаляет их из канала (вызов write() блокируется, пока в канал не будут записаны все данные). Если только один процесс выполняет запись в канал (что обычно и происходит), то все это не имеет значения. Но при наличии нескольких таких процессов большие блоки могут быть разбиты на сегменты произвольного размера (который может быть меньше PIPE_BUF байт) и переданы, чередуясь с блоками других процессов.