UNIX Network Programming. Volume 2 Second Edition. Interprocess Communications

solaris % serverunref2 /tmp/door2

thread id 4, arg = 44

thread id 5, arg = 55

thread id 6, arg = 66

thread id 4 returning

thread id 5 returning

thread id 6 returning

door unreferenced

Проследим за значением счетчика открытых ссылок для этой двери. Он становится равным 1 после вызова door_create, 2 после вызова fattach. Когда три клиента вызывают open, счетчик увеличивается с 2 до 5. После удаления имени файла счетчик уменьшается до 4. После завершения работы трех клиентов счетчик уменьшается с 4 до 1 (последовательно), и последнее его изменение с 2 до 1 приводит к специальному вызову процедуры.

Этими примерами мы показали, что хотя описание атрибута DOOR_UNREF выглядит просто («специальный вызов происходит при изменении счетчика ссылок с 2 до 1»), мы должны понимать принципы работы этого счетчика, чтобы им пользоваться.

15.8. Передача дескрипторов

Когда мы говорим о передаче открытого дескриптора от одного процесса другому, обычно подразумевается одно из двух:

■ наследование всех открытых дескрипторов родительского процесса дочерним после вызова fork;

■ сохранение открытых дескрипторов при вызове exec.

В первом случае процесс открывает дескриптор, вызывает fork, а затем родительский процесс закрывает дескрипторы, предоставляя дочернему возможность работать с ними. При этом открытый дескриптор передается от родительского процесса дочернему.

В современных версиях Unix возможности передачи дескрипторов существенно расширены, и теперь имеется возможность передавать открытый дескриптор от одного процесса другому вне зависимости от их родства. Двери являются одним из существующих интерфейсов для передачи дескрипторов от клиента серверу и от сервера клиенту.

ПРИМЕЧАНИЕ

Передача дескрипторов через доменные сокеты Unix была описана в разделе 14.7 [24]. В ядрах Berkeley и производных от них дескрипторы передаются именно через такие сокеты. Все подробности описаны в главе 18 [23]. В ядрах SVR4 используются другие методы передачи дескрипторов, а именно команды I_SENDFD и I_RECVFD функции ioctl. Они описаны в разделе 15.5.1 [21]. Но процесс в SVR4 может воспользоваться и механизмом доменных сокетов Unix.

Нужно правильно понимать, что именно подразумевается под передачей дескриптора. На рис. 4.7 сервер открывал файл и копировал его целиком через нижний (на рисунке) канал. Если размер файла 1 Мбайт, через канал будет передан 1 Мбайт данных. Но если сервер передает клиенту дескриптор вместо самого файла, то через канал передается только дескриптор (который содержит небольшое количество информации ядра). Клиент может использовать этот дескриптор для считывания содержимого файла. Чтение файла при этом осуществляется именно клиентом, а сервер осуществляет только открытие файла.

Нужно понимать, что сервер не может просто записать в канал числовое значение дескриптора, как в следующем фрагменте кода:

int fd;

fd = Open(…);

Write(pipefd, fd, sizeof(int));

Этот подход не работает. Дескрипторы вычисляются для каждого процесса в отдельности. Предположим, что значение дескриптора файла на сервере равно 4. Даже если дескриптор с тем же значением и открыт клиентом, он почти наверняка относится к другому файлу. Единственная ситуация, в которой дескрипторы одного процесса имеют значение для другого процесса, возникает при вызове fork.

Если первый свободный дескриптор сервера имеет значение 4, вызов open вернет именно это значение. Если сервер передает дескриптор 4 клиенту, а у клиента наименьшее свободное значение дескриптора равно 7, нужно, чтобы дескриптор 7 клиента был установлен в соответствие с тем же файлом, что и дескриптор 4 сервера. Рисунки 15.4 в [21] и 18.4 в [23] иллюстрируют, что должно произойти с точки зрения ядра: два дескриптора (4 у сервера и 7 у клиента) должны указывать на один и тот же файл из таблицы ядра. Интерфейсы типа дверей и доменных сокетов Unix скрывают внутренние детали реализации, предоставляя процессам возможность легко передавать дескрипторы друг другу.