Сигналы изначально были предложены как средство уведомления об ошибках, но могут использоваться и для элементарного IPC, например, для синхронизации процессов или для передачи простейших команд от одного процесса к другому.[42] Однако использование сигналов в качестве средства IPC ограничено из-за того, что сигналы очень ресурсоемки. Отправка сигнала требует выполнения системного вызова, а его доставка — прерывания процесса-получателя и интенсивных операций со стеком процесса для вызова функции обработки и продолжения его нормального выполнения. При этом сигналы слабо информативны и их число весьма ограничено. Поэтому сразу переходим к следующему механизму — каналам.
Каналы
Вспомните синтаксис организации программных каналов при работе в командной строке shell:
cat myfile | wc
При этом (стандартный) вывод программы cat(1), которая выводит содержимое файла myfile, передается на (стандартный) ввод программы wc(1), которая, в свою очередь подсчитывает количество строк, слов и символов. В результате мы получим что-то вроде:
12 45 260
что будет означать количество строк, слов и символов в файле myfile.
Таким образом, два процесса обменялись данными. При этом использовался программный канал, обеспечивающий однонаправленную передачу данных между двумя задачами.
Для создания канала используется системный вызов pipe(2):
int pipe(int* fildes);
который возвращает два файловых дескриптора — fildes[0] для записи в канал и fildes[1] для чтения из канала. Теперь, если один процесс записывает данные в fildes[0], другой сможет получить эти данные из fildes[1]. Вопрос только в том, как другой процесс сможет получить сам файловый дескриптор fildes[1]?
Вспомним наследуемые атрибуты при создании процесса. Дочерний процесс наследует и разделяет все назначенные файловые дескрипторы родительского. То есть доступ к дескрипторам fildes канала может получить сам процесс, вызвавший pipe(2), и его дочерние процессы. В этом заключается серьезный недостаток каналов, поскольку они могут быть использованы для передачи данных только между родственными процессами. Каналы не могут использоваться в качестве средства межпроцессного взаимодействия между независимыми процессами.
Хотя в приведенном примере может показаться, что процессы cat(1) и wc(1) независимы, на самом деле оба этих процесса создаются процессом shell и являются родственными.
Рис. 3.17. Создание канала между задачами cat(1) и wc(1)
FIFO
Название каналов FIFO происходит от выражения First In First Out (первый вошел — первый вышел). FIFO очень похожи на каналы, поскольку являются однонаправленным средством передачи данных, причем чтение данных происходит в порядке их записи. Однако в отличие от программных каналов, FIFO имеют имена, которые позволяют независимым процессам получить к этим объектам доступ. Поэтому иногда FIFO также называют именованными каналами. FIFO являются средством UNIX System V и не используются в BSD. Впервые FIFO были представлены в System III, однако они до сих пор не документированы и поэтому мало используются.
FIFO является отдельным типом файла в файловой системе UNIX (ls -l покажет символ p в первой позиции, см. раздел "Файлы и файловая система UNIX" главы 1). Для создания FIFO используется системный вызов mknod(2):
int mknod(char *pathname, int mode, int dev);
где pathname — имя файла в файловой системе (имя FIFO),
mode — флаги владения, прав доступа и т.д. (см. поле mode файла),
dev — при создании FIFO игнорируется.
FIFO может быть создан и из командной строки shell:
$ mknod <i>name</i> p
После создания FIFO может быть открыт на запись и чтение, причем запись и чтение могут происходить в разных независимых процессах.
Каналы FIFO и обычные каналы работают по следующим правилам:
1. При чтении меньшего числа байтов, чем находится в канале или FIFO, возвращается требуемое число байтов, остаток сохраняется для последующих чтений.
2. При чтении большего числа байтов, чем находится в канале или FIFO, возвращается доступное число байтов. Процесс, читающий из канала, должен соответствующим образом обработать ситуацию, когда прочитано меньше, чем заказано.
3. Если канал пуст и ни один процесс не открыл его на запись, при чтении из канала будет получено 0 байтов. Если один или более процессов открыли канал для записи, вызов read(2) будет заблокирован до появления данных (если для канала или FIFO не установлен флаг отсутствия блокирования O_NDELAY).
4. Запись числа байтов, меньшего емкости канала или FIFO, гарантированно атомарно. Это означает, что в случае, когда несколько процессов одновременно записывают в канал, порции данных от этих процессов не перемешиваются.
5. При записи большего числа байтов, чем это позволяет канал или FIFO, вызов write(2) блокируется до освобождения требуемого места. При этом атомарность операции не гарантируется. Если процесс пытается записать данные в канал, не открытый ни одним процессом на чтение, процессу генерируется сигнал SIGPIPE, а вызов write(2) возвращает 0 с установкой ошибки (errno=ERRPIPE) (если процесс не установил обработки сигнала SIGPIPE, производится обработка по умолчанию — процесс завершается).
В качестве примера приведем простейший пример приложения клиент- сервер, использующего FIFO для обмена данными. Следуя традиции, клиент посылает серверу сообщение "Здравствуй, Мир!", а сервер выводит это сообщение на терминал.
Сервер:
#include <sys/types.h>
#include <sys/stat.h>
#define FIFO "fifo.1"
#define MAXBUFF 80
main() {
int readfd, n;
char buff[MAXBUFF]; /* буфер для чтения данных из FIFO */
/* Создадим специальный файл FIFO с открытыми для всех
правами доступа на чтение и запись */
if (mknod(FIFO, S_IFIFO | 0666, 0) < 0) {
printf("Невозможно создать FIFOn");
exit(1);
}
/* Получим доступ к FIFO */
if ((readfd = open(FIFO, O_RDONLY)) < 0) {
printf("Невозможно открыть FIFOn");
