UNIX: взаимодействие процессов — страница 18 из 35

УДАЛЕННЫЙ ВЫЗОВ ПРОЦЕДУР

ГЛАВА 15Двери

15.1. Введение

Поговорим о схеме клиент-сервер и вызове процедур. Существуют три различных типа вызова процедур, показанные на рис. 15.1.

Рис. 15.1. Три типа вызова процедур

1. Локальный вызов процедуры (local procedure call) знаком нам по обычному программированию на языке С. Вызываемая и вызывающая процедуры (функции) при этом относятся к одному и тому же процессу. При этом обычно выполняется некая команда процессора, передающая управление новой процедуре, а вызвавшая процедура сохраняет значение регистров процессора и выделяет место в стеке Под свои локальные переменные.

2. Удаленный вызов процедуры (remote procedure call — RPC) происходит в ситуации, когда вызвавшая и вызываемая процедуры относятся к разным процессам. В такой ситуации мы обычно называем вызвавшую процедуру клиентом, а вызванную — сервером. Во втором сценарии на рис. 15.1 клиент и сервер выполняются на одном и том же узле. Это типичный частный случай третьего сценария, и это именно то, что осуществляется с помощью дверей (doors). Итак, двери дают возможность вызывать процедуру (функцию) другого процесса на том же узле. Один из процессов (сервер) делает процедуру, находящуюся внутри него, доступной для вызова другим процессам (клиентам), создавая для этой процедуры дверь. Мы можем считать двери специальным типом IPC, поскольку при этом между процессами (клиентом и сервером) передается информация в форме аргументов функции и возвращаемых значений.

3. RPC в общем случае дает возможность клиенту на одном узле вызвать процедуру сервера на другом узле, если эти два узла связаны каким-либо образом по сети (третий сценарий на рис. 15.1). Такой вид взаимодействия будет описан в главе 16.

ПРИМЕЧАНИЕ

Впервые двери были разработаны для распределенной операционной системы Spring. Детали этого проекта доступны по адресу http://www.sun.com/tech/projects/spring. Описание механизма дверей в этой операционной системе можно найти в книге [7].

Затем двери появились в версии Solaris 2.5, хотя единственная страница документации, к ним относящаяся, содержала только предупреждение о том, что двери являются экспериментальным интерфейсом, используемым отдельными приложениями Sun. В Solaris 2.6 описание этого интерфейса занимает уже 8 страниц, но в них он характеризуется как «развивающийся». В будущих версиях Solaris 2.6 описываемый в этой главе интерфейс API может быть изменен. Предварительная версия дверей для Linux уже разрабатывается, детали можно выяснить по адресу http://www.cs.brown.edu/~tor/doors.

Чтобы воспользоваться интерфейсом дверей в Solaris 2.6, нужно подключить соответствующую библиотеку (-ldoor), содержащую функции door_XXX, описываемые в этой главе, и использовать файловую систему ядра (/kernel/sys/doorfs).

Хотя двери поддерживаются только в системе Solaris, мы описываем их достаточно подробно, поскольку это описание позволяет подготовить читателя к удаленному вызову процедур без необходимости обсуждать какие-либо детали сетевого интерфейса. В приложении А мы увидим, что этот интерфейс достаточно быстр — едва ли не быстрее, чем все остальные средства передачи сообщений.

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

Внутри процесса двери идентифицируются дескрипторами. Извне двери могут идентифицироваться именами в файловой системе. Сервер создает дверь вызовом door_create; аргументом этой функции является указатель на процедуру, которая будет связана с данной дверью, а возвращаемое значение является дескриптором двери. Затем сервер связывает полное имя файла с дескриптором двери с помощью функции fattach. Клиент открывает дверь вызовом open, при этом аргументом функции является полное имя файла, которое сервер связал с дверью, а возвращаемым значением — дескриптор, который будет использоваться клиентом для доступа к двери. Затем клиент может вызывать процедуру с помощью door_call. Естественно, программа, являющаяся сервером для некоторой двери, может являться клиентом для другой.

Мы уже сказали, что вызовы через двери являются синхронными: когда клиент вызывает door_call, возврата из этой функции не происходит до тех пор, пока процедура на сервере не завершит работу (возможно, с ошибкой). Реализация дверей в Solaris связана с потоками. Каждый раз, когда клиент вызывает процедуру сервера, для обработки этого вызова создается новый поток в процессе-сервере. Работа с потоками обычно осуществляется автоматически функциями библиотеки дверей, при этом потоки создаются по мере необходимости, но мы увидим, что сервер может и сам управлять этими потоками, если это требуется. Это также означает, что одна и та же процедура может выполняться сервером для нескольких клиентов, причем для каждого из них будет создан отдельный поток. Такой сервер является параллельным. Поскольку одновременно могут выполняться несколько экземпляров процедуры сервера (каждая из которых представляет собой отдельный поток), содержимое этих процедур должно соответствовать определенным требованиям, которые обычно предъявляются к многопоточным программам.

При удаленном вызове процедуры и данные, и дескрипторы могут быть переданы от клиента к серверу. Обратно также могут быть переданы данные и дескрипторы. Передача дескрипторов вообще является неотъемлемым свойством дверей. Более того, поскольку двери идентифицируются дескрипторами, это позволяет процессу передать дверь другому процессу. Более подробно о передаче дескрипторов будет говориться в разделе 15.8.

Пример

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

Листинг 15.1 .Клиент передает серверу длинное целое для возведения его в квадрат

//doors/client1.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int fd;
6   long ival, oval;
7   door_arg_t arg;
8   if (argc != 3)
9    err_quit("usage: client1 ");
10  fd = Open(argv[1], O_RDWR); /* открываем дверь */
11  /* задаем аргументы и указатель на результат */
12  ival = atol(argv[2]);
13  arg.data_ptr = (char *) &ival; /* аргументы */
14  arg.data_size = sizeof(long); /* размер аргументов */
15  arg.desc_ptr = NULL;
16  arg.desc_num = 0;
17  arg.rbuf = (char *) &oval; /* результат */
18  arg.rsize = sizeof(long); /* размер результата */
19  /* вызываем процедуру на сервере и выводим результат */
20  Door_call(fd, &arg);
21  printf("result: %ld\n", oval);
22  exit(0);
23 }

Открываем дверь

8-10 Дверь задается полным именем, передаваемым в качестве аргумента командной строки. Она открывается вызовом open. Возвращаемый дескриптор называется дескриптором двери, но часто его самого и называют дверью.

Подготовка аргументов и указателя на результат

11-18 Структура arg содержит указатели на аргументы и результат. Поле data_ptr указывает на первый байт аргументов, a data_size содержит количество байтов в аргументах. Два поля desc_ptr и desc_num предназначены для передачи дескрипторов, о чем мы будем подробно говорить в разделе 15.8. rbuf указывает на первый байт буфера результата, a rsize задает его размер.

Вызов процедуры на сервере и вывод результата

19-21 Мы вызываем процедуру на сервере с помощью door_call; аргументами этого вызова являются дескриптор двери и указатель на структуру аргументов. После возвращения из этого вызова программа печатает получившийся результат.

Программа-сервер приведена в листинге 15.2. Она состоит из процедуры сервера с именем servproc и функции main.

Листинг 15.2. Сервер, возводящий длинное целое в квадрат

//doors/server1.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   arg = *((long *) dataptr);
8   result = arg * arg;
9   Door_return((char *) &result, sizeof(result), NULL, 0);
10 }

11 int
12 main(int argc, char **argv)
13 {
14  int fd;
15  if (argc != 2)
16   err_quit("usage: server1 ");
17  /* создание двери и связывание ее с файлом */
18  fd = Door_create(servproc, NULL, 0);
19  unlink(argv[1]);
20  Close(Open(argv[1], O_CREAT | O_RDWR, FILE_MODE));
21  Fattach(fd, argv[1]);
22  /* функция servproc() обрабатывает все запросы клиентов */
23  for (;;)
24   pause();
25 }

Процедура сервера

2-10 Процедура сервера вызывается с пятью аргументами, но мы используем только один из них — dataptr. Он указывает на первый байт аргумента. Аргумент, представляющий собой длинное целое, передается через этот указатель и возводится в квадрат. Управление передается клиенту вместе с результатом вызовом door_return. Первый аргумент указывает на результат, второй задает его размер, а оставшиеся предназначены для возврата дескрипторов.

Создание дескриптора двери и связывание с ним файла

17-21 Дескриптор двери создается вызовом door_create. Первый аргумент является указателем на функцию, соответствующую этой двери (servproc). После получения этого дескриптора его нужно связать с некоторым именем в файловой системе, поскольку оно будет использоваться клиентом для подключения к этой двери. Делается это путем создания обычного файла в файловой системе (сначала мы вызываем unlink, на тот случай, если такой файл уже существует, причём возможная ошибка игнорируется) и вызова fattach — функции SVR4, связывающей дескриптор с полным именем файла.

Главный поток сервера ничего не делает

22-24 Главный поток сервера блокируется при вызове pause. Вся функциональность обеспечивается функцией servproc, которая будет запускаться как отдельный поток каждый раз при получении запроса клиента.

Запустим сервер в отдельном окне:

solaris % server1 /tmp/server1

После этого запустим пpoгрaммy-клиeнт в другом окне, указав в качестве аргумента то же полное имя, которое было указано при вызове сервера:

solaris % client1 /tmp/server19
result: 81
solaris % ls -l /tmp/server1
Drw-r-r– 1 rstevens other1 0 Apr 9 10:09 /tmp/server1

Мы получили ожидаемый результат. Вызвав ls, мы видим, что эта пpoгрaммa выводит букву D в начале строки, соответствующей файлу, указывая, что этот файл является дверью.

На рис. 15.2 приведена диaгрaммa работы данного примера. Функция door_call вызывает процедуру на сервере, которая затем вызывает door_return для возврата.

На рис. 15.3 приведена диaгрaммa, показывающая, что в действительности происходит при вызове процедуры в другом процессе на том же узле.

Рис. 15.2. Внешний вид вызова процедуры в другом процессе

На рис. 15.3 выполняются следующие действия:

0. Запускается сервер, вызывает door_create, чтобы создать дескриптор для функции servproc, затем связывает этот дескриптор с именем файла в файловой системе.

1. Запускается клиент и вызывает door_call. Это функция в библиотеке дверей.

2. Библиотечная функция door_call делает системный вызов. При этом указывается процедура, которая должна быть выполнена, а управление передается функции из библиотеки дверей процесса-сервера.

3. Вызывается процедура сервера (servproc в данном примере).

4. Процедура сервера делает все необходимое для обработки запроса клиента и вызывает door_return по завершении работы.

5. Библиотечная функция door_return осуществляет системный вызов, передавая управление ядру.

6. В этом вызове указывается процесс-клиент, которому и передается управление.

Рис. 15.3. Что в действительности происходит при вызове процедуры в другом процессе

Последующие разделы этой главы описывают интерфейс дверей (doors API) более подробно, с множеством примеров. В приложении А мы убедимся, что двери представляют собой наиболее быструю форму IPC (при измерении времени ожидания).

15.2. Функция door_call

Функция door_call вызывается клиентом для обращения к процедуре сервера, выполняемой в адресном пространстве процесса-сервера:

#include 
int door_call(int fd, door_arg_t *argp);
/* Возвращает 0 в случае успешного завершения. –1 – в случае ошибки */

Дескриптор fd обычно возвращается функцией open (см. листинг 15.1). Полное имя файла, открываемого клиентом, однозначно идентифицирует процедуру сервера, которая вызывается door_call при передаче дескриптора.

Второй аргумент — argp — указывает на структуру, описывающую аргументы и приемный буфер для возвращаемых значений:

typedef struct door_arg {
 char *data_ptr; /* при вызове указывает на аргументы, при возврате – на результаты */
 size_t data_size; /* при вызове определяет общий размер аргументов в байтах, при возврате – общий размер возвращаемых данных в байтах */
 door_desc_t *desc_ptr; /* при вызове указывает на аргументы-дескрипторы, при возврате указывает на возвращаемые дескрипторы */
 size_t desc_num; /* при вызове задает количество аргументов-дескрипторов, при возврате задает количество возвращаемых дескрипторов */
 char *rbuf; /* указатель на буфер результатов */
 size_t rsize; /* размер буфера результатов */ 
} door_arg_t;

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

ПРИМЕЧАНИЕ

Использование типа char* для двух указателей кажется странным и требует использования явного преобразования типов для предотвращения вывода предупреждений компилятора. Естественно было бы использовать указатели типа void*. С указателями char* мы еще столкнемся в функции door_return. Вероятно, в Solaris 2.7 тип данных desc_num изменится на unsigned int и последний аргумент door_return изменится соответствующим образом.

Аргументы и результаты могут быть двух типов: данные и дескрипторы.

■ Аргументы-данные представляют собой последовательность данных длиной data_size байт. На эту последовательность должен указывать data_ptr. Клиент и сервер должны заранее знать формат этих данных (и аргументов, и результатов). Нет способа указать серверу тип аргументов. В пpoгрaммax листингов 15.1 и 15.2 клиент и сервер были написаны таким образом, что они оба знали, что аргумент представлял собой одно длинное целое и возвращаемый результат также был одним длинным целым. Для скрытия внутреннего устройства передаваемых данных их можно объединить в структуру, что упростит работу тому, кто будет читать код несколько лет спустя. Итак, все аргументы можно заключить в одну структуру, результаты — в другую и обе их определить в одном заголовочном файле, используемом клиентом и сервером. Пример будет приведен в листингах 15.8 и 15.9. Если аргументов-данных нет, указатель data_ptr должен быть нулевым и размер данных data_size должен иметь значение 0.

ПРИМЕЧАНИЕ

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

■ Аргументы-дескрипторы хранятся в массиве структур door_desc_t, каждая из которых содержит один передаваемый от клиента серверу дескриптор. Количество структур типа door_desc_t задается аргументом desc_num. (Мы описываем эту структуру и смысл «передачи дескриптора» в разделе 15.8.) Если аргументов-дескрипторов нет, следует передать нулевой указатель desc_ptr и присвоить полю desc_num значение 0.

■ При возврате из функции data_ptr указывает на результаты-данные, a data_size задает размер возвращаемых данных. Если никакие данные не возвращаются, data_size будет иметь значение 0, а значение указателя data_ptr следует игнорировать.

■ Функция может возвращать и дескрипторы, при этом desc_ptr указывает на массив структур типа door_desc_t, каждая из которых содержит один передаваемый сервером клиенту дескриптор. Количество возвращаемых структур типа door_desc_t хранится в поле desc_num. Если дескрипторы не возвращаются, значение desc_num будет равно 0, а указатель desc_ptr следует игнорировать.

Можно спокойно использовать один и тот же буфер для передаваемых аргументов и возвращаемых результатов. При вызове door_call и data_ptr, и desc_ptr могут указывать на буфер, указанный аргументом rbuf.

Перед вызовом door_call клиент устанавливает указатель rbuf на буфер для результатов, a rsize делает равным размеру буфера. После возвращения из функции и data_ptr, и desc_ptr будут указывать на этот буфер. Если он слишком мал для хранения результатов, возвращаемых сервером, библиотека дверей автоматически выделит новый буфер в адресном пространстве клиента с помощью mmap (раздел 12.2) и обновит значения rbuf и rsize соответствующим образом. Поля data_ptr и desc_ptr будут указывать на новый буфер. Клиент отвечает за то, чтобы обнаружить изменение этих указателей и впоследствии освободить занимаемую память вызовом munmap с аргументами rbuf и rsize. Пример будет приведен в листинге 15.4.

15.3. Функция door_create

Процесс-сервер определяет некоторую функцию как процедуру сервера вызовом door_create:

#include 
typedef void Door_server_proc(void *cookie, char *dataptr, size_t datasize, door_desc_t *descptr, size_t ndesc);
int door_create(Door_server_proc *proc, void *cookie, u_int attr);
/* Возвращает неотрицательный дескриптор в случае успешного завершения, –1 –в случае ошибки */

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

Когда сервер вызывает door_create, первый аргумент (proc) указывает адрес процедуры сервера, которая будет вызываться через дескриптор двери, возвращаемый этим вызовом. При вызове процедуры сервера ее аргумент cookie содержит значение, передаваемое в качестве второго аргумента door_create. Это дает серверу возможность передавать процедуре какой-либо указатель каждый раз, когда эта процедура вызывается клиентом. Следующих четыре аргумента процедуры сервера — dataptr, datasize, descptr и ndesc — описывают аргументы-данные и аргументы-дескрипторы клиента. Они соответствуют первым четырем полям структуры door_arg_t, описанной в предыдущем разделе.

Последний аргумент door_create(attr) описывает специальные атрибуты процедуры сервера и может быть равен либо 0, либо логической сумме двух констант:

■ DOOR_PRIVATE — библиотека дверей автоматически создает новые потоки в процессе-сервере при поступлении запросов от клиентов. По умолчанию эти потоки помещаются в пул потоков и могут использоваться для обслуживания запросов клиентов по всем дверям данного процесса.

Указание атрибута DOOR_PRIVATE говорит библиотеке, что для данной двери следует создать собственный пул потоков, отдельный от пула потоков процесса.

■ DOOR_UNREF — когда количество дескрипторов, открытых для данной двери, изменяется с двух до одного, процедура сервера вызывается со вторым аргументом, имеющим значение DOOR_UNREF_DATA. При этом аргумент descptr представляет собой нулевой указатель, а аргументы datasize и ndesc равны нулю. Мы приведем пример использования этого атрибута в листинге 15.13.

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

В листинге 15.2 мы видели, что после получения дескриптора двери вызовом door_create сервер должен вызвать fattach для связывания этого дескриптора с некоторым файлом. Клиент затем может открыть этот файл для получения дескриптора двери, который впоследствии может быть использован при вызове door_call.

ПРИМЕЧАНИЕ

Функция fattach не включена в стандарт Posix.1, но ее наличие требуется стандартом Unix 98. Кроме того, этот стандарт определяет также функцию fdetach, отключающую связь дескриптора и файла, и программу fdetach, вызывающую эту функцию.

Для дескрипторов дверей, создаваемых door_create, устанавливается бит FD_CLOEXEC. Это означает, что дескриптор закрывается при вызове процессом функций типа exec. Что касается вызова fork, несмотря на то что открытые родительским процессом дескрипторы используются дочерним процессом совместно с ним, только родительский процесс будет принимать вызовы от клиентов. Дочерним процессам вызовы не передаются, хотя дескриптор, возвращаемый door_create, и будет в них открыт.

ПРИМЕЧАНИЕ

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

15.4. Функция door_return

После завершения работы процедуры сервера возврат из нее осуществляется вызовом door_return. Это приводит к возврату из door_call соответствующего клиента. 

#include 
int door_return(char *dataptr, size_t datasize, door_desc_t *descptr, size_t ndesc);
/* Ничего не возвращает вызвавшему процессу в случае успешного завершения. –1 – в случае ошибки */

Возвращаемые данные задаются аргументами dataptr и datasize, а возвращаемые дескрипторы — descptr и ndesc.

15.5. Функция door_cred

Интерфейс дверей предусматривает полезную возможность получения информации о клиенте при каждом вызове. Это осуществляется функцией door_cred:

#include 
int door_cred(door_cred_t *cred);
/* Возвращает 0 в случае успешного завершения, –1 – в случае ошибки */

Структура, на которую указывает аргумент cred, имеет тип door_cred_t, определяемый как

typedef struct door_cred {
 uid_t dc_euid; /* действующий идентификатор пользователя клиента */
 gid_t dc_egid; /* действующий идентификатор группы клиента */
 uid_t dc_ruid; /* реальный идентификатор пользователя клиента */
 gid_t dc_rgid; /* реальный идентификатор группы клиента */
 pid_t dc_pid; /* идентификатор процесса клиента */
} door_cred_t;

В эту структуру помещается информация о клиенте при возвращении из вызова door_cred. В разделе 4.4 [21] подробно рассказывается о различиях между действующими и реальными идентификаторами пользователя и группы, а пример использования этой функции приведен в листинге. 15.5.

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

15.6. Функция door_info

Только что описанная функция door_cred предоставляет серверу информацию о клиенте. Клиент же может получить информацию о сервере, вызвав doo_info:

#include 
int door_info(int fd, door_info_t *info);
/* Возвращает 0 в случае успешного завершения, –1 – в случае ошибки */

Дескриптор fd указывает на открытую дверь. Структура типа door_info_t, на которую указывает info, после возвращения из функции содержит информацию о сервере:

typedef struct doo_info {
 pid_t di_target; /* идентификатор процесса сервера */
 door_ptr_t di_proc; /* процедура сервера */
 door_ptr_t di_data; /* принимаемые процедурой сервера данные */
 door_attr_t di_attributes; /* атрибуты, связанные с данной дверью */
 door_id_t di_uniquifier; /* уникальный номер двери */
} door info t;

Поле di_target содержит идентификатор процесса сервера, a di_proc — адрес процедуры сервера в процессе (от которого клиенту, вообще говоря, пользы мало). Указатель, передаваемый процедуре сервера в качестве первого аргумента (cookie), возвращается клиенту в поле di_data.

Текущие атрибуты двери помещаются в поле di_attributes, и два из них уже были описаны в разделе 15.3. Это атрибуты DOOR_PRIVATE и DOOR_UNREF. Два других атрибута называются DOOR_LOCAL (процедура является локальной для данного процесса) и DOOR_REVOKE (сервер аннулировал процедуру, связанную с этой дверью, вызвав door_revoke).

Каждой двери при создании сопоставляется уникальный в пределах системы номер, который возвращается в поле di_uniquifier.

Эта функция обычно вызывается клиентом для получения информации о сервере. Однако она может быть вызвана и из процедуры сервера, причем первым аргументом в этом случае должна быть константа DOOR_QUERY. Тогда функция возвратит информацию о вызвавшем потоке, то есть о данном экземпляре процедуры сервера. В этом случае адреса процедуры сервера и принимаемых аргументов (di_proc и di_data) могут представлять интерес.

15.7. Примеры

В этом разделе мы приведем примеры использования пяти только что описанных функций.

Функция door_info

В листинге 15.3 приведен текст программы, открывающей дверь и вызывающей door_infо для получения информации об этой двери, которая затем выводится на экран.

Листинг 15.3. Вывод информации о двери

//doors/doorinfo.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int fd;
6   struct stat stat;
7   struct door_info info;
8   if (argc != 2)
9    err_quit("usage; doorinfo ");
10  fd = Open(argv[1], O_RDONLY);
11  Fstat(fd, &stat);
12  if (S_ISDOOR(stat.st_mode) == 0)
13   err_quit("pathname is not a door");
14  Door_info(fd, &info);
15  printf("server PID = %ld, uniquifier = %ld",
16   (long)info.di_target, (long)info.di_uniquifier);
17  if (info.di_attributes & DOOR_LOCAL)
18   printf(", DOOR_LOCAL");
19  if (info.di_attributes & DOOR_PRIVATE)
20   printf(", DOOR_PRIVATE");
21  if (info.di_attributes & DOOR_REVOKED)
22   printf(", DOOR_REVOKED");
23  if (info.di_attributes & DOOR_UNREF)
24   printf(", DOOR_UNREF");
25  printf("\n");
26  exit(0);
27 }

Сначала программа открывает файл с указанным полным именем и проверяет, что это действительно дверь. Поле st_mode структуры stat в этом случае должно содержать такое значение, что макрос S_ISDOOR будет возвращать значение «истина». Затем вызывается функция door_info.

Сначала мы укажем этой программе полное имя файла, не являющегося дверью, а затем попробуем получить информацию о двух встроенных дверях Solaris 2.6:

solaris % doorinfo/etc/passwd
pathname is not a door
solaris % doorinfo /etc/.name_service_door
server PID = 308, uniquifier = 18, DOOR_UNREF
solaris % doorinfo /etc/.syslog_door
server PID = 282, uniquifier = 1635
solaris % ps –f -p 308
root 308 1 0 Apr 01 ? 0:34 /usr/sbin/nscd
solaris % ps –f -p 282
root 282 1 0 Apr 01 ? 0:10 /usr/sbin/syslogd –n –z 14

Команду ps мы используем для того, чтобы узнать, какая программа выполняется с идентификатором, возвращаемым door_info.

Буфер результатов слишком мал

Когда мы рассказывали о функции door_call, мы отметили, что если буфер результатов оказывается слишком мал, библиотека дверей осуществляет автоматическое выделение нового буфера. Сейчас мы покажем это на примере. В листинге 15.4 приведен текст новой программы-клиента, которая представляет собой измененную версию листинга 15.2.

Листинг 15.4. Вывод адреса полученного результата

//doors/client2.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int fd;
6   long ival, oval;
7   door_arg_t arg;
8   if (argc != 3)
9    err_quit("usage: client2 ");
10  fd = Open(argv[1], O_RDWR); /* открываем дверь */
11  /* подготовка аргументов и указателя на результат */
12  ival = atol(argv[2]);
13  arg.data_ptr = (char *) &ival; /* аргументы-данные */
14  arg.data_size = sizeof(long); /* объем данных */
15  arg.desc_ptr = NULL;
16  arg.desc_num = 0;
17  arg.rbuf = (char *) &oval; /* возвращаемые данные */
18  arg.rsize = sizeof(long); /* объем возвращаемых данных */
19  /* вызов процедуры сервера и вывод результата */
20  Door_call(fd, &arg);
21  printf("&oval = %p, data_ptr = %p, rbuf = %p, rsize = %d\n",
22   &oval, arg.data_ptr, arg.rbuf, arg.rsize);
23  printf("result: %ld\n", *((long *) arg.data_ptr));
24  exit(0);
25 }

19-22 В этой версии программы на экран выводится адрес переменной oval, содержимое указателя data_ptr, который должен указывать на возвращаемые функцией door_call данные, и адрес и размер приемного буфера (rbuf и rsize).

Запустим эту программу, не изменяя размер приемного буфера по сравнению с листингом 15.2. Мы ожидаем, что data_ptr и rbuf будут указывать на переменную oval и rsize будет иметь значение 4 (4 байта в буфере). И действительно, вот что мы видим:

solaris % client2 /tmp/server2 22
&oval = effff740, data_ptr = effff740, rbuf = effff740, rsize = 4
result: 484

Изменим только одну строку в листинге 15.4, уменьшив размер буфера клиента до одного байта. Новый вариант строки 18 будет иметь вид:

arg.rsize = sizeof(long) – 1; /* размер буфера данных */

Запустим новую программу и увидим, что библиотека автоматически выделила место под новый буфер результатов и data_ptr теперь указывает на новый буфер:

solaris % client3 /tmp/server3 33
&oval = effff740, data_ptr = ef620000, rbuf = ef620000, rsize = 4096
result: 1089

Размер выделенного буфера равен 4096 байт, что совпадает с размером страницы в данной системе, который мы узнали в разделе 12.6. Этот пример показывает, что следует всегда обращаться к результатам через указатель data_ptr, а не через переменные, адреса которых были переданы в rbuf. В нашем примере к результату типа «длинное целое» следует обращаться как *(long*)arg.data_ptr, а не oval (что мы делали в листинге 15.2).

Новый буфер выделяется вызовом mmap и может быть возвращен системе с помощью munmap. Клиент может повторно использовать этот буфер при новых вызовах door_call.

Функция door_cred и информация о клиенте

На этот раз мы изменим нашу функцию servproc из листинга 15.3, добавив в нее вызов door_cred для получения информации о пользователе. В листинге 15.5 приведен текст новой процедуры сервера; функции main клиента и сервера не претерпевают изменений по сравнению с листингами 15.2 и 15.3.

Листинг 15.5. Процедура сервера, получающая информацию о клиенте

//doors/server4.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   door_cred_t info;
8   /* получение и вывод информации о клиенте */
9   Door_cred(&info);
10  printf("euid = %ld, ruid = %ld, pid = %ld\n",
11  (long) info.dc_euid, (long) info.dc_ruid, (long) info.dc_pid);
12  arg = *((long *) dataptr);
13  result = arg * arg;
14  Door_return((char *) &result, sizeof(result), NULL, 0);
15 }

Сначала мы запустим программу-клиент и увидим, что действующий и реальный идентификаторы клиента совпадают, как мы и предполагали. Затем мы сменим владельца исполняемого файла на привилегированного пользователя, установим бит SUID и запустим программу снова:

solaris % client4 /tmp/server4 77 первый запуск клиента
result: 5929
solaris % su                      вход под именем привилегированного пользователя
Password:
Sun Microsystems Inc. Sun OS 5.6 Generic August 1997
solaris # cd                     каталог, в котором находится исполняемый файл
solaris # ls –l client4
-rwxrwxr-x 1 rstevens other1 139328 Apr 13 06:02 client4
solaris # chown root client4     смена владельца на привилегированного пользователя
solaris # chmod u+s client4      включение бита SUID
solaris # ls -l client4           проверка разрешений и владельца файла
-rwsrwxr-x 1 root     other1 139328 Apr 13 06:02 client4
solaris # exit
solaris % ls -l client4
-rwsrwxr-x 1 root     other1 139328 Apr 13 06:02 client4
solaris % client4 /tmp/server477 и еще раз запускаем программу-клиент
result: 5929

Если мы посмотрим, что в это время выводил сервер, то увидим следующую картину:

solaris % server4 /tmp/server4
euid = 224, ruid = 224, pid = 3168
euid = 0, ruid = 224, pid = 3176

Действующий идентификатор пользователя при втором запуске изменился. Значение 0 означает привилегированного пользователя.

Автоматическое управление потоками сервера

Чтобы посмотреть, как осуществляется управление потоками сервера, добавим в процедуру сервера команду выдачи ее идентификатора потока. Добавим в нее также пятисекундную паузу, чтобы имитировать длительное выполнение. За это время мы сможем запустить несколько клиентов. В листинге 15.6 приведен текст новой процедуры сервера.

Листинг 15.6. Процедура сервера, выводящая идентификатор потока

//doors/server5.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   arg = *((long *) dataptr);
8   printf("thread id %ld, arg = %ld\n", pr_thread_id(NULL), arg);
9   sleep(5);
10  result = arg * arg;
11  Door_return((char*)&result, sizeof(result), NULL, 0);
12 }

Здесь используется новая функция из нашей библиотеки — pr_thread_id. Она принимает один аргумент (указатель на идентификатор потока или нулевой указатель вместо идентификатора вызвавшего потока) и возвращает идентификатор этого потока (обычно небольшое целое число, но всегда в формате длинного целого). Процессу всегда можно сопоставить целое число — его идентификатор. Хотя мы и не знаем, к какому типу принадлежит идентификатор процесса (int или long), мы просто преобразуем значение, возвращаемое getpid, к типу long и выводим значение (листинг 9.2). Однако идентификатор потока принадлежит к типу pthread_t, который не обязательно является одним из целых типов. И действительно, в Solaris 2.6 идентификаторами потоков являются короткие целые, тогда как в Digital Unix используются указатели. Однако часто возникает необходимость сопоставлять потокам небольшие целые числа для задач отладки (как в данном примере). Наша библиотечная функция, текст которой приведен в листинге 15.7, решает этот вопрос.

Листинг 15.7. Функция pr_thread_id: возвращает небольшой целочисленный идентификатор потока

//lib/wrappthread.c
245 long
246 pr_thread_id(pthread_t *ptr)
247 {
248 #if defined(sun)
249  return((ptr == NULL) ? pthread_self() : *ptr); /* Solaris */
250 #elif defined(__osf__) && defined(__alpha)
251  pthread_t tid;
252  tid = (ptr == NULL) ? pthread_self() : *ptr; /* Digital Unix */
253  return(pthread_getsequence_np(tid));
254 #else
255  /* прочие системы */
256  return((ptr == NULL) ? pthread_self() : *ptr);
257 #endif
258 }

Если в данной реализации идентификатор потока не является небольшим целым числом, функция может быть сложнее. Она может осуществлять отображение значений типа pthread_t в целые числа и сохранять эти отображения для последующих вызовов в массиве или связном списке. Эта задача решена в функции thread_name в книге [13].

Вернемся к программе из листинга 15.6. Запустим ее три раза подряд. Поскольку нам приходится ждать возвращения подсказки интерпретатора, чтобы запустить клиент еще раз, мы можем быть уверены, что каждый раз выполняется пятисекундная пауза:

solaris % client5 /tmp/server5 55
result: 3025
solaris % client5 /tmp/server5 66
result: 4356
solaris % client5 /tmp/server5 77
result: 5929

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

solaris % server5 /tmp/server5
thread id 4, arg = 55
thread id 4, arg = 66
thread id 4, arg = 77

Теперь запустим три экземпляра программы-клиента одновременно:

solaris % client5 /tmp/server5 11 & client5 /tmp/server5 22 & client5 /tmp/server5 33 &
[2] 3812
[3] 3813
[4] 3814
solaris % result: 484
result: 121
result: 1089

Выводимый сервером текст показывает, что для обработки второго и третьего вызова процедуры сервера создаются новые потоки:

thread id 4, arg = 22
thread id 5, arg = 11
thread id 6, arg = 33

Затем мы запустим еще два клиента одновременно (первые три уже завершили работу):

solaris % client5 /tmp/server5 11 & client5 /tmp/server5 22 &
[2] 3830
[3] 3831
solaris % result: 484
result: 121

При этом сервер использует созданные ранее потоки:

thread id 6, arg = 22
thread id 5, arg = 11

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

Мы также убедились, что сервер в этом случае является параллельным (concurrent): одновременно может выполняться несколько экземпляров процедуры сервера в виде отдельных потоков для обслуживания клиентов. Это следует также из того, что результат работы сервера выводится тремя экземплярами клиента одновременно пять секунд спустя после их одновременного запуска. Если бы сервер был последовательным, первый результат появился бы через 5 секунд после запуска, следующий — через 10, а последний — через 15.

Автоматическое управление потоками сервера: несколько процедур

В предыдущем примере процесс-сервер содержал лишь одну процедуру сервера. Вопрос, которым мы займемся теперь, звучит так: могут ли несколько процедур одного процесса использовать один и тот же пул потоков сервера? Чтобы узнать ответ, добавим к нашему серверу еще одну процедуру, а заодно перепишем наши программы заново, чтобы продемонстрировать более приличный стиль передачи аргументов и результатов между процессами.

Первый файл в этом примере называется squareproc.h. В нем определен один тип данных для входных аргументов функции, возводящей в квадрат, и еще один — для возвращаемых ею результатов. В этом заголовочном файле также определяется полное имя двери для данной процедуры. Его текст его приведен в листинге 15.8.

Листинг 15.8. Заголовочный файл squareproc.h

//doors/squareproc.h
1 #define PATH_SQUARE_DOOR "/tmp/squareproc_door"

2 typedef struct { /* аргументы squareproc() */
3  long arg1;
4 } squareproc_in_t;

5 typedef struct { /* возврат squareproc() */
6  long res1;
7 } squareproc_out_t;

Наша новая процедура будет принимать длинное целое и возвращать квадратный корень из него (типа double). Мы определяем полное имя двери этой процедуры, структуры аргументов и результатов в заголовочном файле sqrtproc.h в листинге 15.9.

Листинг 15.9. Заголовочный файл sqrtproc.h

//doors/sqrtproc.h
1 #define PATH_SQRT_DOOR "/tmp/sqrtproc_door"

2 typedef struct { /* входные данные sqrtproc() */
3  long arg1;
4 } sqrtproc_in_t;

5 typedef struct { /* возвращаемые sqrtproc() данные */
6  double res1;
7 } sqrtproc_out_t;

Программа-клиент приведена в листинге 15.10. Она последовательно вызывает две процедуры сервера и выводит возвращаемые ими результаты. Эта программа устроена аналогично другим клиентским программам, приведенным в этой главе.

Листинг 15.10. Клиент, вызывающий две процедуры

//doors/client7.c
1  #include "unpipc.h"
2  #include "squareproc.h"
3  #include "sqrtproc.h"

4  int
5  main(int argc, char **argv)
6  {
7   int fdsquare, fdsqrt;
8   door_arg_t arg;
9   squareproc_in_t square_in;
10  squareproc_out_t square_out;
11  sqrtproc_in_t sqrt_in;
12  sqrtproc_out_t sqrt_out;
13  if (argc != 2)
14   err_quit("usage: client7 ");
15  fdsquare = Open(PATH_SQUARE_DOOR, O_ROWR);
16  fdsqrt = Open(PATH_SQRT_DOOR, O_RDWR);
17  /* подготовка аргументов и вызов squareproc() */
18  square_in.arg1 = atol(argv[1]);
19  arg.data_ptr = (char*)&square_in;
20  arg.data_size = sizeof(square_in);
21  arg.desc_ptr = NULL;
22  arg.desc_num = 0;
23  arg.rbuf = (char*)&square_out;
24  arg.rsize = sizeof(square_out);
25  Door_call(fdsquare, &arg);
26  /* подготовка аргументов и вызов sqrtproc() */
27  sqrt_in.arg1 = atol(argv[1]);
28  arg.data_ptr = (char*)&sqrt_in;
29  arg.data_size = sizeof(sqrt_in);
30  arg.desc_ptr = NULL;
31  arg.desc_num = 0;
32  arg.rbuf = (char*)&sqrt_out;
33  arg.rsize = sizeof(sqrt_out);
34  Door_call(fdsqrt, &arg);
35  printf("result: %ld %g\n", square_out.res1, sqrt_out.res1);
36  exit(0);
37 }

Текст двух серверных процедур приведен в листинге 15.11. Каждая из них выводит текущий идентификатор потока и значение аргумента, делает 5-секунд-ную паузу, вычисляет результат и завершает работу.

Листинг 15.11. Две процедуры сервера

//doors/server7.c
1  #include "unpipc.h"
2  #include 
3  #include "squareproc.h"
4  #include "sqrtproc.h"

5  void
6  squareproc(void *cookie, char *dataptr, size_t datasize,
7   door_desc_t *descptr, size_t ndesc)
8  {
9   squareproc_in_t in;
10  squareproc_out_t out;
11  memcpy(&in, dataptr, min(sizeof(in), datasize));
12  printf("squareproc: thread id %ld, arg = %ld\n",
13   pr_thread_id(NULL), in.arg1);
14  sleep(5);
15  out.res1 = in.arg1 * in.arg1;
16  Door_return((char *) &out, sizeof(out), NULL, 0);
17 }

18 void
19 sqrtproc(void *cookie, char *dataptr, size_t datasize,
20  door_desc_t *descptr, size_t ndesc)
21 {
22  sqrtproc_in_t in;
23  sqrtproc_out_t out;
24  memcpy(&in, dataptr, min(sizeof(in), datasize));
25  printf("sqrtproc: thread id %ld, arg = %ld\n",
26   pr_thread_id(NULL), in.arg1);
27  sleep(5);
28  out.res1 = sqrt((double)in.arg1);
29  Door_return((char *) &out, sizeof(out), NULL, 0);
30 }

Функция main сервера, текст которой приведен в листинге 15.12, открывает дескрипторы дверей и связывает каждый из них с одной из процедур сервера.

Листинг 15.12. Функция main сервера

//doors/server7.c
31 int
32 main(int argc, char **argv)
33 {
34  int fd;
35  if (argc != 1)
36   err_quit("usage: server7");
37  fd = Door_create(squareproc, NULL, 0);
38  unlink(PATH_SQUARE_DOOR);
39  Close(Open(PATH_SQUARE_DOOR, O_CREAT | O_RDWR, FILE_MODE));
40  Fattach(fd, PATH_SQUARE_DOOR);
41  fd = Door_create(sqrtproc, NULL, 0);
42  unlink(PATH_SQRT_DOOR);
43  Close(Open(PATH_SQRT_DOOR, O_CREAT | O_RDWR, FILE_MODE));
44  Fattach(fd, PATH_SQRT_DOOR);
45  for (;;)
46   pause();
47 }

Запустим программу-клиент и подождем 10 секунд до вывода результатов (как мы и ожидали):

solaris % client7 77
result: 5929 8.77496

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

solaris % server7
squareproc: thread id 4, arg = 77
sqrtproc: thread id 4, arg = 77

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

Атрибут DOOR_UNREF для серверов

В разделе 15.3 мы отметили, что при вызове door_create для создаваемой двери можно указать атрибут DOOR_UNREF. В документации говорится, что если количество дескрипторов, относящихся к этой двери, уменьшается с двух до одного, осуществляется специальный вызов процедуры сервера. Особенность вызова заключается в том, что второй аргумент процедуры сервера (указатель на данные) при этом является константой DOOR_UNREF_DATA. Мы продемонстрируем три способа обращения к двери.

1. Дескриптор, возвращаемый door_create, считается первой ссылкой на эту дверь. Вообще говоря, причина, по которой специальный вызов происходит при изменении количества дескрипторов с 2 на 1, а не с 1 на 0, заключается в том, что первый дескриптор обычно не закрывается сервером до завершения работы.

2. Полное имя, связанное с дверью в файловой системе, также считается ссылкой на дверь. Ее можно удалить вызовом функции fdetach, или запустив программу fdetach, или удалив полное имя из файловой системы (функцией unlink или командой rm).

3.  Дескриптор, возвращаемый клиенту функцией open, считается открытой ссылкой до тех пор, пока не будет закрыт либо явным вызовом close, либо неявно, при завершении клиента. Во всех примерах этой главы дескриптор закрывается неявно.

Первый пример показывает, что если сервер закрывает свой дескриптор после вызова fattach, немедленно происходит специальный вызов процедуры сервера. В листинге 15.13 приведен текст процедуры сервера и функции main.

Листинг 15.13. Процедура сервера, обрабатывающая специальный вызов

//doors/serverunref1.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   if (dataptr == DOOR_UNREF_DATA) {
8    printf("door unreferenced\n");
9    Door_return(NULL, 0, NULL, 0);
10  }
11  arg = *((long*)dataptr);
12  printf("thread id %ld, arg = %ld\n", pr_thread_id(NULL), arg);
13  sleep(6);
14  result = arg * arg;
15  Door_return((char *)&result, sizeof(result), NULL, 0);
16 }

17 int
18 main(int argc, char **argv)
19 {
20  int fd;
21  if (argc != 2)
22   err_quit("usage: server1 ");
23  /* создание дескриптора и связывание с файлом */
24  fd = Door_create(servproc, NULL, DOOR_UNREF);
25  unlink(argv[1]);
26  Close(Open(argv[1], O_CREAT | O_RDWR, FILE_MODE));
27  Fattach(fd, argv[1]);
28  Close(fd);
29  /* процедура servproc() обрабатывает все запросы клиентов */
30  for(;;)
31   pause();
32 }

7-10 Процедура сервера распознает специальный вызов и выводит сообщение об этом. Возврат из специального вызова происходит путем вызова door_return с двумя нулевыми указателями и нулевыми значениями размеров.

28 Теперь мы закрываем дескриптор двери после выполнения fattach. Этот дескриптор может быть нужен серверу только для вызовов door_bind, doo_info и door_revoke.

Запустив сервер, мы увидим, что немедленно произойдет специальный вызов:

solaris % serverunref1 /tmp/door1
door unreferenced

Если мы проследим за значением счетчика открытых дескрипторов, мы увидим, что он становится равен 1 после возврата из door_create и 2 после возврата из fattach. Вызов close уменьшает количество открытых дескрипторов с двух до одного, что приводит к специальному вызову процедуры. Единственная оставшаяся ссылка при этом представляет собой имя в файловой системе, а этого клиенту достаточно, чтобы обратиться к двери. Поэтому клиент продолжает работать правильно:

solaris % clientunref1 /tmp/door1 11
result: 121
solaris % clientunref1 /tmp/door1 22
result: 484

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

Теперь изменим нашу программу-сервер обратно, убрав вызов close для дескриптора двери. Процедура сервера и функция main приведены в листинге 15.14.

Листинг 15.14. Сервер, не закрывающий дескриптор двери

//doors/serverunref2.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie. char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   if (dataptr == DOOR_UNREF_DATA) {
8    printf("door unreferenced\n");
9    Door_return(NULL, 0, NULL, 0);
10  }
11  arg = *((long *)dataptr);
12  printf("thread id %ld, arg = %ld\n", pr_thread_id(NULL), arg);
13  sleep(6);
14  result = arg * arg;
15  printf("thread id %ld returning\n", pr_thread_id(NULL));
16  Door_return((char *)&result, sizeof(result), NULL, 0);
17 }

18 int
19 main(int argc, char **argv)
20 {
21  int fd;
23  if (argc != 2)
24   err_quit("usage: server1 ");
25  /* создание двери, дескриптора и подключение к файлу */
26  fd = Door_create(servproc, NULL, DOOR_UNREF);
27  unlink(argv[1]);
28  Close(Open(argv[1], O_CREAT | O_RDWR, FILE_MODE));
29  Fattach(fd, argv[1]);
30  /* servproc() обрабатывает все запросы клиентов */
31  for(;;)
32   pause();
33 }

Мы оставляем 6-секундную паузу и выводим сообщение о возврате из процедуры сервера. Запустим сервер в одном окне, а из другого проверим существование имени файла двери в файловой системе и удалим его с помощью rm:

solaris % ls –l /tmp/door2
Drw-r--r-- 1 rstevens other1 0 Apr 16 08:58 /tmp/door2
solaris % rm /tmp/door2

После удаления имени файла происходит специальный вызов процедуры сервера:

solaris % serverunref2 /trap/door2
door unreferenced после удаления файла из файловой системы

Если мы проследим за количеством ссылок на эту дверь, то увидим следующее: одна ссылка появляется после вызова door_create, вторая — после fattach. После удаления файла с помощью rm количество ссылок снова уменьшается до единицы, что приводит к специальному вызову процедуры.

В последнем примере использования этого атрибута мы снова удалим имя из файловой системы. Но на этот раз мы сначала запустим три экземпляра программы-клиента. Специальный вызов процедуры произойдет только после завершения последнего клиента, потому что каждый экземпляр клиента увеличивает количество ссылок на дверь. Используем сервер из листинга 15.14 и клиент из листинга 15.2.

solaris % clientunref2 /tmp/door2 44 & clientunref2 /tmp/door2 55 & clientunref2/tmp/door2 55 &
[2] 13552
[3] 13553
[4] 13554
solaris % rm /tmp/door2 клиенты все еще выполняются
solaris % result: 1936
result: 3025
result: 4356

Сервер при этом выведет вот что:

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 скрывают внутренние детали реализации, предоставляя процессам возможность легко передавать дескрипторы друг другу.

Дескрипторы передаются через дверь от клиента серверу путем присваивания полю desc_ptr структуры door_arg_t значения указателя на массив структур типа door_desc_t и помещения в поле desc_num количества этих структур. Дескрипторы передаются от сервера клиенту путем присваивания третьему аргументу door_return значения указателя на массив структур door_desc_t и помещения в четвертый аргумент количества передаваемых дескрипторов:

Рис. 15.4. Сервер файлов, передающий клиенту дескриптор

typedef struct door_desc {
 door_attr_t d_attributes; /* тег объединения */
 union {
  struct { /* верна, если tag = DOOR_DESCRIPTOR */
   int d_descriptor; /* номер дескриптора */
   door_id_t d_id; /* уникальный идентификатор */
  } d_desc;
 } d_data;
} door_desc_t;

Эта структура содержит объединение (union), и первое поле структуры является тегом, идентифицирующим содержимое этого объединения. В настоящий момент определено только одно поле объединения (структура d_desc, описывающая дескриптор), и тег (d_attributes) должен иметь значение DOOR_DESCRIPTOR.

Пример

Изменим наш пример с сервером файлов таким образом, чтобы сервер открывал файл, передавал дескриптор клиенту, а клиент копировал содержимое файла в стандартный поток вывода. На рис. 15.4 приведена схема приложения. В листинге 15.15 приведен текст программы клиента.

Листинг 15.15. Клиент для сервера, передающего дескриптор

//doors/clientfd1.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int door, fd;
6   char argbuf[BUFFSIZE], resbuf[BUFFSIZE], buff[BUFFSIZE];
7   size_t len, n;
8   door_arg_t arg;
9   if (argc != 2)
10   err_quit("usage: clientfd1 ");
11  door = Open(argv[1], O_RDWR); /* открываем дверь */
12  Fgets(argbuf, BUFFSIZE, stdin); /* считываем полное имя открываемого файла */
13  len = strlen(argbuf);
14  if (argbuf[len-1] == '\n')
15   len--;
16  /* подготавливаем аргумент и указатель на результат */
17  arg.data_ptr = argbuf; /* аргумент-данные */
18  arg.data_size = len + 1; /* размер данных */
19  arg.desc_ptr = NULL;
20  arg.desc_num = 0;
21  arg.rbuf = resbuf; /* результаты-данные */
22  arg.rsize = BUFFSIZE; /* размер возвращаемых данных */
23  Door_call(door, &arg); /* вызов процедуры сервера */
24  if (arg.data_size != 0)
25   err_quit("%.*s", arg.data_size, arg.data_ptr);
26  else if (arg.desc_ptr == NULL)
27   err_quit("desc_ptr is NULL");
28  else if (arg.desc_num != 1)
29   err_quit("desc_num = %d", arg.desc_num);
30  else if (arg.desc_ptr->d_attributes != DOOR_DESCRIPTOR)
31   err_quit("d_attributes = %d", arg.desc_ptr->d_attributes);
32  fd = arg.desc_ptr->d_data.d_desc.d_descriptor;
33  while((n = Read(fd, buff, BUFFSIZE)) > 0)
34   Write(STDOUT_FILENO, buff, n);
35  exit(0);
36 }

Открываем дверь, считываем полное имя файла

9-15 Имя файла, связанного с дверью, принимается в качестве аргумента командной строки. Имя файла, который должен быть открыт и выведен, считывается из стандартного потока ввода, а завершающий символ перевода строки удаляется.

Подготовка аргументов и указателя на буфер возврата

16-22 Подготавливается структура door_arg_t. К размеру имени файла мы добавляем единицу, чтобы сервер мог дополнить его завершающим нулем.

Вызов процедуры сервера и проверка результатов

23-31 Мы вызываем процедуру сервера и проверяем результат. Должен возвращаться только один дескриптор и никаких данных. Вскоре мы увидим, что сервер возвращает данные (сообщение об ошибке) только в том случае, если он не может открыть файл. В этом случае функция err_quit выводит сообщение об ошибке.

Считывание дескриптора и копирование файла

32-34 Дескриптор извлекается из структуры door_desc_t, и файл копируется в стандартный поток вывода.

В листинге 15.16 приведен текст процедуры сервера. Функция main по сравнению с листингом 15.3 не изменилась.

Листинг 15.16. Процедура сервера, открывающая файл и возвращающая клиенту дескриптор

//doors/serverfd1.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   int fd;
7   char resbuf[BUFFSIZE];
8   door_desc_t desc;
9   dataptr[datasize-1] = 0; /* завершающий О */
10  if ((fd = open(dataptr, O_RDONLY)) == –1) {
11   /* ошибка, нужно сообщить клиенту */
12   snprintf(resbuf, BUFFSIZE, "%s: can't open, %s",
13   dataptr, strerror(errno));
14   Door_return(resbuf, strlen(resbuf), NULL, 0);
15  } else {
16   /* ОК, возвращаем дескриптор */
17   desc.d_data.d_desc.d_descriptor = fd;
18   desc.d_attributes = DOOR_DESCRIPTOR;
19   Door_return(NULL, 0, &desc, 1);
20  }
21 }

Открытие файла для клиента

9-14 Мы завершаем полное имя файла клиента нулем и делаем попытку открыть этот файл вызовом open. Если возникает ошибка, сообщение о ней возвращается клиенту.

Успешное открытие файла

15-20 Если файл был успешно открыт, клиенту возвращается только его дескриптор.

Запустим сервер и укажем ему имя двери /tmp/fd1, а затем запустим клиент:

solaris % clientfd1 /tmp/fd1
/etc/shadow
/etc/shadow: can't open. Permission denied
solaris % clientfd1 /tmp/fd1
/no/such/file
/no/such/file: can't open. No such file or directory
solaris % clientfd1 /tmp/fd1
/etc/ntp.conf файл из двух строк
multicastclient 224.0.1.1
driftfile /etc/ntp.drift

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

ПРИМЕЧАНИЕ

Существует проблема, связанная с передачей дескриптора через дверь. Чтобы она проявилась в нашем примере, достаточно добавить вызов printf к процедуре сервера сразу после успешного вызова open. Вы увидите, что значение дескриптора каждый раз увеличивается на единицу. Проблема в том, что сервер не закрывает дескрипторы после передачи их клиенту. Сделать это, вообще говоря, нелегко. Логично было бы выполнять закрытие дескриптора после возврата из door_return, после успешной отправки дескриптора клиенту, но возврата из door_return не происходит! Если бы мы использовали sendmsg для передачи дескриптора через доменный сокет Unix или ioctl для передачи дескриптора через канал в SVR4, мы могли бы закрыть его после возврата из sendmsg или ioctl. Однако с дверьми все по-другому, поскольку возврата из функции door_return не происходит. Единственный способ обойти проблему заключается в том, что процедура сервера должна запоминать все открытые дескрипторы и закрывать их некоторое время спустя, что несколько запутывает код.

Эта проблема должна быть исправлена в Solaris 2.7 добавлением атрибута DOOR RELEASE. Отправитель устанавливает поле d_attributes равным DOOR DESCRIPTOR | DOOR_RELEASE, что говорит системе о необходимости закрывать дескриптор после передачи его клиенту.

15.9. Функция door server_create

В листинге 15.6 мы показали, что библиотека дверей автоматически создает новые потоки для обслуживания запросов клиентов по мере их поступления. Они создаются библиотекой как неприсоединенные потоки (detached threads) с размером стека потока по умолчанию, с отключенной возможностью отмены потока (thread cancellation) и с маской сигналов и классом планирования (scheduling class), унаследованными от потока, вызвавшего door_create. Если мы хотим изменить какой-либо из этих параметров или хотим самостоятельно работать с пулом потоков сервера, можно воспользоваться функцией door_server_create и указать нашу собственную процедуру создания сервера:

#include 
typedef void Door_create_proc(door_info_t *);
Door_create_proc *door_server_create(Door_create_proc *proc);
/* Возвращает указатель на предыдущую процедуру создания сервера */

Как и при объявлении door_create в разделе 15.3, мы используем оператор typedef для упрощения прототипа библиотечной функции. Наш новый тип данных определяет процедуру создания сервера как принимающую один аргумент (указатель на структуру типа door_info_t) и ничего не возвращающую (void). При вызове door_server_create аргументом является указатель на нашу процедуру создания сервера, а возвращается указатель на предыдущую процедуру создания сервера. 

Наша процедура создания сервера вызывается при возникновении необходимости создания нового потока для обслуживания запроса клиента. Информация о том, какой из процедур сервера требуется новый поток, передается в структуре door_info_t, адрес которой принимается процедурой создания сервера. Поле di_proc содержит адрес процедуры сервера, а поле di_data содержит указатель на аргументы, передаваемые процедуре сервера при вызове.

Проще всего изучить происходящее на примере. Программа-клиент не претерпевает никаких изменений по сравнению с листингом 15.1. В программу-сервер добавляются две новые функции помимо процедуры сервера и функции main. На рис. 15.5 приведена схема сервера с четырьмя функциями и последовательностью их регистрации и вызова.

Рис. 15.5. Четыре функции в процессе-сервере

В листинге 15.17 приведен текст функции main сервера.

Листинг 15.17. Функция main для примера с управлением пулом потоков

//doors/server6.c
42 int
43 main(int argc, char **argv)
44 {
45  if (argc != 2)
46  err_quit("usage: server6 ");
47  Door_server_create(my_create);
48  /* создание дескриптора двери и связывание его с именем */
49  Pthread_mutex_lock(&fdlock);
50  fd = Door_create(servproc, NULL, DOOR_PRIVATE);
51  Pthread_mutex_unlock(&fdlock);
52  unlink(argv[1]);
53  Close(Open(argv[1], O_CREAT | O_RDWR, FILE_MODE));
54  Fattach(fd, argv[1]);
55  /* servproc() обслуживает запросы клиентов */
56  for(;;)
57   pause();
58 }

По сравнению с листингом 15.2 было внесено четыре изменения:

1. Убрано объявление дескриптора двери fd (теперь это глобальная переменная, описанная в листинге 15.18).

2. Вызов door_create защищен взаимным исключением (также описанным в листинге 15.18).

3. Вызов door_server_create делается перед созданием двери, при этом указывается процедура создания сервера (my_thread, которая, будет показана позже).

4. В вызове door_create последний аргумент (атрибуты) имеет значение DOOR_PRIVATE вместо 0. Это говорит библиотеке о том, что данная дверь будет иметь собственный пул потоков, называемый частным пулом сервера.

Задание процедуры создания сервера с помощью door_server_create и выделение частного пула сервера с помощью DOOR_PRIVATE осуществляются независимо друг от друга. Возможны четыре ситуации:

1. По умолчанию частный пул сервера и процедура создания сервера отсутствуют. Система создает потоки по мере необходимости и они переходят в пул потоков процесса.

2. Указан флаг DOOR_PRIVATE, но процедура создания сервера отсутствует. Система создает потоки по мере необходимости и они отходят в пул потоков процесса, если относятся к тем дверям, для которых флаг DOOR_PRIVATE не был указан, либо в пул данной двери, если она была создана с флагом DOOR_PRIVATE.

3. Отсутствует частный пул сервера, но указана процедура создания сервера. Процедура создания вызывается при необходимости создания нового потока, который затем переходит в пул потоков процесса.

4. Указан флаг DOOR_PRIVATE и процедура создания сервера. Процедура создания сервера вызывается каждый раз при необходимости создания потока. После создания поток должен вызвать door_bind для отнесения его к нужному частному пулу сервера, иначе он будет добавлен к пулу потоков процесса.

В листинге 15.18 приведен текст двух новых функций: my_create (процедура создания сервера) и my_thread (функция, выполняемая каждым потоком, который создается my_create).

Листинг 15.18. Функции управления потоками

//doors/server6.c
13 pthread_mutex_t fdlock = PTHREAD_MUTEX_INITIALIZER;
14 static int fd = –1; /* дескриптор двери */

15 void *
16 my_thread(void *arg)
17 {
18  int oldstate;
19  door_info_t *iptr = arg;
20  if ((Door_server_proc*)iptr->di_proc == servproc) {
21   Pthread_mutex_lock(&fdlock);
22   Pthread_mutex_unlock(&fdlock);
23   Pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate);
24   Door_bind(fd);
25   Door_return(NULL, 0, NULL, 0);
26  } else
27   err_quit("my_thread: unknown function: %p", arg);
28  return(NULL); /* никогда не выполняется */
29 }

30 void
31 my_create(door info_t *iptr)
32 {
33  pthread_t tid;
34  pthread_attr_t attr;
35  Pthread_attr_init(&attr);
36  Pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);
37  Pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
38  Pthread_create(&tid, &attr, my_thread, (void *)iptr);
39  Pthread_attr_destroy(&attr);
40  printf("my_thread: created server thread %ld\n", pr_thread_id(&tid)):
41 }

Процедура создания сервера

30-41 Каждый раз при вызове my_create создается новый поток. Перед вызовом pthread_create атрибуты потока инициализируются, область потока устанавливается равной PTHREAD_SCOPE_SYSTEM и поток определяется как неприсоединенный (detached). Созданный поток вызывает функцию my_thread. Аргументом этой функции является указатель на структуру типа door_info_t. Если у нас имеется сервер с несколькими дверьми и мы указываем процедуру создания сервера, эта процедура создания сервера будет вызываться при необходимости создания потока для любой из дверей. Единственный способ, которым эта процедура может определить тип сервера, соответствующий нужной двери, заключается в изучении указателя di_proc в структуре типа door_info_t.

ПРИМЕЧАНИЕ

Установка области выполнения PTHREAD_SCOPE_SYSTEM означает, что поток будет конкурировать в распределении ресурсов процессора с другими потоками системы. Альтернативой является указание PTHREAD_SCOPE_PROCESS; при этом поток будет конкурировать только с другими потоками данного процесса. Последнее не будет работать с дверьми, поскольку библиотека дверей требует, чтобы тот процесс ядра, который привел к вызову данного потока, выполнял и door_return. Поток с PTHREAD_SCOPE_PROCESS может сменить поток ядра во время выполнения процедуры сервера.

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

Функция, запускающая поток

15-20 При создании потока запускается функция my_thread, указанная в вызове pthread_create. Аргументом является указатель на структуру типа door_info_t, передаваемый my_create. В данном примере есть только одна процедура сервера — servproc, и мы просто проверяем, что аргумент указывает на эту процедуру.

Ожидание присваивания дескриптору правильного значения

21-22 Процедура создания сервера вызывается в первый раз при вызове door_create для создания первого потока сервера. Этот вызов осуществляется из библиотеки дверей до завершения работы door_create. Однако переменная fd не примет значения дескриптора двери до тех пор, пока не произойдет возврата из функции door_create (проблема курицы и яйца). Поскольку мы знаем, что my_thread выполняется отдельно от основного потока, решение состоит в том, чтобы использовать взаимное исключение fdlock следующим образом: основной поток блокирует взаимное исключение перед вызовом door_create и разблокирует после возврата из door_create (когда дескриптору fd уже присвоено некоторое значение). Функция my_thread делает попытку заблокировать взаимное исключение (ее выполнение приостанавливается до тех пор, пока основной поток не разблокирует это взаимное исключение), а затем разблокирует его. Мы могли бы добавить условную переменную и передавать по ней уведомление, но здесь это не нужно, поскольку мы заранее знаем, в каком порядке будут происходить вызовы.

Отключение отмены потока

23 При создании нового потока вызовом pthread_create его отмена по умолчанию разрешена. Если отмена потока разрешена и клиент прерывает вызов door_call в процессе его выполнения (что мы продемонстрируем в листинге 15.26), вызываются обработчики отмены потока, после чего он завершается. Если отмена потока отключена (как это делаем мы) и клиент прерывает работу в вызове door_call, процедура сервера спокойно завершает работу (поток не завершается), а результаты door_return просто сбрасываются. Поскольку серверный поток завершается, если происходит отмена потока, и поскольку процедура сервера может в этот момент выполнять какие-то действия (возможно, с заблокированными семафорами или блокировками), библиотека дверей на всякий случай отключает отмену всех создаваемых ею потоков. Если нам нужно, чтобы процедура сервера отменялась при досрочном завершении работы клиента, для этого потока следует включить возможность отмены и приготовиться обработать такую ситуацию.

ПРИМЕЧАНИЕ

Обратите внимание, что область выполнения PTHREAD_SCOPE_SYSTEM и неприсоединенность потока указываются как атрибуты при создании потока. А отмена потока может быть отключена только в процессе выполнения потока. Таким образом, хотя мы и отключаем отмену потока, он сам может ее включить и выключить тогда, когда потребуется.

Связывание потока с дверью

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

Делаем поток доступным клиенту

25 Мы делаем поток доступным клиенту вызовом door_return с двумя нулевыми указателями и нулевыми значениями длин буферов в качестве аргументов.

Процедура сервера приведена в листинге 15.19. Она идентична программе из листинга 15.6.

Листинг 15.19. Процедура сервера

//doors/server6.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   arg = *((long *) dataptr);
8   printf("thread id %ld, arg = %ld\n", pr_thread_id(NULL), arg);
9   sleep(5);
10  result = arg * arg;
11  Door_return((char *)&result, sizeof(result), NULL, 0);
12 }

Чтобы продемонстрировать работу программы, запустим сервер:

solaris % server6 /tmp/door6
my_thread: created server thread 4

После запуска сервера и вызова door_create процедура создания сервера запускается в первый раз, хотя клиент мы еще не запустили. При этом создается первый поток, ожидающий запроса от первого клиента. Затем мы запускаем клиент три раза подряд:

solaris % client6 /tmp/door6 11
result: 121
solaris % client6 /tmp/door6 22
result: 484
solaris % client6 /tmp/door6 33
result: 1089

Посмотрим, что при этом выводит сервер. При поступлении первого запроса клиента создается новый поток (с идентификатором потока 5), а поток с номером 4 обслуживает все запросы клиентов. Библиотека дверей всегда держит один лишний поток наготове:

my_thread: created server thread 5
thread id 4, arg = 11
thread id 4, arg = 22
thread id 4, arg = 33

Запустим теперь три экземпляра клиента одновременно в фоновом режиме:

solaris % client6 /tmp/door6 44 &client6 /tmp/door6 55 &client6 /tmp/door6 66 &
[2] 4919
[3] 4920
[4] 4921
solaris % result: 1936
result: 4356
result: 3025

Посмотрев на вывод сервера, мы увидим, что было создано два новых потока (с идентификаторами 6 и 7) и потоки 4, 5 и 6 обслужили три запроса от клиентов:

thread id 4, arg = 44
my_thread: created server thread 6
thread id 5, arg = 66
my_thread: created server thread 7
thread id 6, arg = 55

15.10. Функции door_bind, door unbind и door_revoke

Рассмотрим еще три функции, дополняющие интерфейс дверей:

#include 
int door_bind(int fd);
int door_unbind(void);
int door_revoke(int fd);
/* Всe три возвращают 0 в случае успешного завершения, –1 – в случае ошибки */

Функция door_bind впервые появилась в листинге 15.18. Она связывает вызвавший ее поток с частным пулом сервера, относящимся к двери с дескриптором fd. Если вызвавший поток уже подключен к какой-либо другой двери, производится его неявное отключение.

Функция door_unbind осуществляет явное отключение потока от текущего пула, к которому он подключен.

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

15.11. Досрочное завершение клиента или сервера

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

Досрочное завершение сервера

Если клиент блокируется в вызове door_call, ожидая получения результатов, ему нужно каким-то образом получить уведомление о завершении потока сервера по какой-либо причине. Посмотрим, что происходит в этом случае, прервав работу сервера вызовом pthread_exit. Это приведет к завершению потока сервера (а не всего процесса). В листинге 15.20 приведен текст процедуры сервера.

Листинг 15.20. Процедура сервера, завершающая работу сразу после запуска

//doors/serverintr1.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   pthread_exit(NULL); /* посмотрим, что произойдет с клиентом */
8   arg = *((long*)dataptr);
9   result = arg * arg;
10  Door_return((char*)&result, sizeof(result), NULL, 0);
11 }

Оставшаяся часть сервера не претерпевает изменений по сравнению с листингом 15.2, а программу-клиент мы берем из листинга 15.1.

Запустив клиент, мы увидим, что вызов door_call возвращает ошибку EINTR, если процедура сервера завершается досрочно:

solaris % clientintr1 /tmp/door1 11
door_call error: Interrupted system call

Непрерываемость системного вызова door_call

Документация на door_call предупреждает, что эта функция не предполагает возможности перезапуска (библиотечная функция door_call делает системный вызов с тем же именем). Мы можем убедиться в этом, изменив процедуру сервера таким образом, чтобы она делала паузу в 6 секунд перед возвращением, что показано в листинге 15.21.

Листинг 15.21. Процедура сервера делает паузу в 6 секунд

//doors/serverintr2.с
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4  door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result;
7   sleep(6); /* клиент получает сигнал SIGCHLD */
8   arg = *((long*)dataptr);
9   result = arg * arg;
10  Door_return((char*)&result, sizeof(result), NULL, 0);
11 }

Изменим теперь клиент из листинга 15.2: установим обработчик сигнала SIGCHLD, добавив порождение процесса и завершение порожденного процесса через 2 секунды. Таким образом, через 2 секунды после вызова door_call дочерний процесс завершит работу, а родительский перехватит сигнал SIGCHLD и произойдет возврат из обработчика сигнала, прерывающий системный вызов door_call. Текст программы-клиента показан в листинге 15.22.

Листинг 15.22. Клиент, перехватывающий сигнал SIGCHLD

//doors/clientintr2.c
1  #include "unpipc.h"

2  void
3  sig_chld(int signo)
4  {
5   return; /* просто прерываем door_call() */
6  }

7  int
8  main(int argc, char **argv)
9  {
10  int fd;
11  long ival, oval;
12  door_arg_t arg;
13  if (argc != 3)
14   err_quit("usage: clientintr2 ");
15  fd = Open(argv[1], O_RDWR); /* открываем дверь */
16  /* подготовка аргументов и указателя на результат */
17  ival = atol(argv[2]);
18  arg.data_ptr = (char*)&ival; /* аргументы */
19  arg.data_size = sizeof(long); /* размер аргументов */
20  arg.desc_ptr = NULL;
21  arg.desc_num = 0;
22  arg.rbuf = (char*)&oval; /* данные */
23  arg.rsize = sizeof(long); /* размер данных */
24  Signal(SIGCHLD, sig_chld);
25  if (Fork() == 0) {
26   sleep(2); /* дочерний процесс */
27   exit(0); /* отправка SIGCHLD */
28  }
29  /* вызов процедуры сервера и вывод результата */
30  Door_call(fd, &arg);
31  printf(result: %ld\n", oval);
32  exit(0);
33 }

Клиенту будет возвращена та же ошибка, что и при досрочном завершении сервера — EINTR:

solaris % clientintr2 /tmp/door2 22
door_call error: interrupted system call

Поэтому нужно блокировать все сигналы, которые могут прервать вызов door_call.

Идемпотентные и неидемпотентные процедуры

А что произойдет, если мы перехватим сигнал EINTR и вызовем процедуру сервера еще раз, поскольку мы знаем, что эта ошибка возникла из-за нашего собственного прерывания системного вызова перехваченным сигналом (SIGCHLD)? Это может привести к некоторым проблемам, как мы покажем ниже.

Изменим сервер так, чтобы он выводил идентификатор вызванного потока, делал паузу в 6 секунд и выводил идентификатор потока по завершении его. В листинге 15.23 приведен текст новой процедуры сервера. 

Листинг 15.23. Процедура сервера, выводящая свой идентификатор потока дважды

//doors/serverintr3.c
1  #include "unpipc.h"

2  void
3  servproc(void *cookie, char *dataptr, size_t datasize,
4   door_desc_t *descptr, size_t ndesc)
5  {
6   long arg, result:
7   printf("thread id %ld called\n", pr_thread_id(NULL));
8   sleep(6); /* даем клиенту возможность перехватить SIGCHLD */
9   arg = *((long*)dataptr);
10  result = arg * arg;
11  printf("thread id %ld returning\n", pr_thread_id(NULL));
12  Door_return((char *) &result, sizeof(result), NULL, 0);
13 }

В листинге 15.24 приведен текст программы-клиента.

Листинг 15.24. Клиент, вызывающий door_call еще раз, после перехвата EINTR

//doors/clientintr3.c
1  #include "unpipc.h"
2  volatile sig_atomic_t caught_sigchld;

3  void
4  sig_chld(int signo)
5  {
6   caught_sigchld = 1;
7   return; /* прерываем вызов door_call() */
8  }

9  int
10 main(int argc, char **argv)
11 {
12  int fd, rc;
13  long ival, oval;
14  door_arg_t arg;
15  if (argc != 3)
16   err_quit("usage: clientintr3 ");
17  fd = Open(argv[1], O_RDWR); /* открытие двери */
18  /* подготовка аргументов и указателя на результаты */
19  ival = atol(argv[2]);
20  arg.data_ptr = (char*)&ival; /* аргументы */
21  arg.data_size = sizeof(long); /* размер аргументов */
22  arg.desc_ptr = NULL;
23  arg.desc_num = 0;
24  arg.rbuf = (char*)&oval; /* возвращаемые данные */
25  arg.rsize = sizeof(long); /* размер данных */
26  Signal(SIGCHLD, sig_chld);
27  if (Fork() == 0) {
28   sleep(2); /* дочерний процесс */
29   exit(0); /* отправка SIGCHLD */
30  }
31  /* родительский процесс : вызов процедуры сервера и вывод результата */
32  for (;;) {
33   printf("calling door_call\n");
34   if ((rc = door_call(fd, &arg)) == 0)
35    break; /* успешное завершение */
36   if (errno == EINTR && caught_sigchld) {
37    caught_sigchld = 0;
38    continue; /* повторный вызов door_call */
39   }
40   err_sys("door_call error");
41  }
42  printf("result: %ld\n", oval);
43  exit(0);
44 }

2-8 Объявляем глобальную переменную caught_sigchld, устанавливая ее в единицу при перехвате сигнала SIGCHLD.

31-42 Вызываем door_call в цикле, пока он не завершится успешно.

Глядя на выводимые клиентом результаты, мы можем подумать, что все в порядке:

solaris % clientintr3 /tmp/door3 33
calling door_call
calling door_call
result: 1089

Функция door_call вызывается в первый раз, обработчик сигнала срабатывает через 2 секунды после этого и переменной caught_sigchld присваивается значение 1. door_call при этом возвращает ошибку EINTR и мы вызываем door_call еще раз. Во второй раз процедура завершается успешно.

Посмотрев на выводимый сервером текст, мы увидим, что процедура сервера была вызвана дважды:

solaris % serverintr3 /tmp/door3
thread id 4 called
thread id 4 returning
thread id 5 called
thread id 5 returning

Когда клиент второй раз вызывает door_call, это приводит к запуску нового потока, вызывающего процедуру сервера еще раз. Если процедура сервера идемпотентна, проблем в такой ситуации не возникнет. Однако если она неидемпотентна, это может привести к ошибкам.

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

Досрочное завершение клиента

Посмотрим, каким образом процедура сервера получает уведомление о досрочном завершении клиента. Пpoгрaммa-клиeнт приведена в листинге 15.25.

Листинг 15.25. Клиент, досрочно завершающий работу после вызова door_call

//doors/clientintr4.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int fd;
6   long ival, oval;
7   door_arg_t arg;
8   if (argc != 3)
9    err_quit("usage: clientintr4 ");
10  fd = Open(argv[1], O_RDWR); /* открываем дверь */
11  /* подготовка аргументов и указателя на результаты */
12  ival = atol(argv[2]);
13  arg.data_ptr = (char*)&ival; /* аргументы */
14  arg.data_size = sizeof(long); /* размер аргументов */
15  arg.desc_ptr = NULL;
16  arg.desc_num = 0;
17  arg.rbuf = (char*)&oval; /* возвращаемые данные */
18  arg.rsize = sizeof(long); /* размер возвращаемых данных */
19  /* вызов процедуры сервера и вывод результата */
20  alarm(3);
21  Door_call(fd, &arg);
22  printf("result: %ld\n", oval);
23  exit(0);
24 }

20 Единственное изменение заключается в добавлении вызова alarm(3) перед door_call. Эта функция приводит к отправке сигнала SIGALRM через три секунды после вызова, но, поскольку мы его не перехватываем, это приводит к завершению процесса. Поэтому клиент завершится до возврата из door_call, потому что в процедуру сервера вставлена шестисекундная пауза.

В листинге 15.26 приведен текст процедуры сервера и обработчик отмены потока.

Листинг 15.26. Процедура сервера, обрабатывающая досрочное завершение клиента

//doors/serverintr4.с 
1  #include "unpipc.h"
2  void
3  servproc_cleanup(void *arg)
4  {
5   printf("servproc cancelled, thread id %ld\n", pr_thread_id(NULL));
6  }

7  void
8  servproc(void *cookie, char *dataptr, size_t datasize,
9   door_desc_t *descptr, size_t ndesc)
10 {
11  int oldstate, junk;
12  long arg, result;
13  Pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, &oldstate);
14  pthread_cleanup_push(servproc_cleanup, NULL);
15  sleep(6);
16  arg = *((long*)dataptr);
17  result = arg * arg;
18  pthread_cleanup_pop(0);
19  Pthread_setcancelstate(oldstate, &junk);
20  Door_return((char*)&result, sizeof(result), NULL, 0);
21 }

Вспомните, что мы говорили об отмене выполнения потока в разделе 8.5 и в связи с листингом 15.18. Когда система обнаруживает завершение клиента в процессе выполнения серверной процедуры, потоку, обрабатывающему запрос этого клиента, отправляется запрос на отмену:

■ если поток отключил возможность отмены, ничего не происходит и поток выполняется до завершения (вызов door_return), а результаты сбрасываются;

■ если возможность отмены включена, вызываются обработчики отмены потока, а затем он завершает работу.

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

В текст процедуры сервера мы добавляем 6-секундную паузу, чтобы клиент мог успешно завершить работу в вызове door_call.

Запустив клиент дважды, мы увидим сообщение интерпретатора Alarm clock при завершении процесса сигналом SIGALRM:

solaris % clientintr4 /tmp/door4 44
Alarm Clock
solaris % clientintr4 /tmp/door4 44
Alarm Clock

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

solaris % serverintr4 /tmp/door4
servproc canceled, thread id 4
servproc canceled, thread id 5

Цель, с которой мы вызываем программу-клиент дважды, — показать, что после завершения потока с идентификатором 4 библиотека создает новый поток (с идентификатором 5) для обработки второго запроса клиента.

15.12. Резюме

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

Основные функции этого интерфейса просты в работе и использовании. Сервер вызывает door_create для создания двери и связывания ее с процедурой сервера, а затем вызывает fattach для сопоставления этой двери и имени файла в файловой системе. Клиент вызывает open для этого имени файла и затем может вызвать door_call для вызова процедуры сервера. Возврат из процедуры сервера осуществляется вызовом door_return.

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

Двери предоставляют возможность передачи дескрипторов от клиента серверу и обратно. Это достаточно мощное средство, поскольку дескрипторы в Unix дают возможность обращаться ко множеству объектов (файлам, сокетам или XTI, дверям).

При вызове процедур в другом процессе следует учесть возможность досрочного завершения клиента или сервера. Клиент получает уведомление о досрочном завершении сервера с помощью сообщения об ошибке EINTR. Сервер получает уведомление о досрочном завершении клиента в процессе обработки процедуры посредством запроса на отмену выполнения потока данной процедуры. Сервер может обработать этот запрос или проигнорировать его.

Упражнения

1. Сколько байтов информации передается при вызове door_call от клиента серверу?

2. Есть ли необходимость вызывать fstat для проверки типа дескриптора в листинге 15.3? Уберите этот вызов и посмотрите, что произойдет.

3. В документации Solaris 2.6 для вызова sleep() говорится, что «выполнение текущего процесса приостанавливается». Почему при этом библиотека дверей имеет возможность создать новые потоки в листинге 15.6?

4. В разделе 15.3 мы отмечали, что для создаваемых вызовом door_create дверей автоматически устанавливается бит FD_CLOEXEC. Однако мы можем вызвать fcntl после возврата из door_create и сбросить этот бит. Что произойдет, если мы сделаем это, вызовем exec, а затем обратимся к процедуре сервера из клиента?

5. В листингах 15.23 и 15.24 добавьте вывод текущего времени в вызовах printf сервера и клиента. Запустите клиент и сервер. Почему первый экземпляр процедуры сервера возвращается через две секунды после запуска?

6. Удалите блокировку, защищающую дескриптор fd в листингах 15.17 и 15.18, и убедитесь, что программа больше не работает. Какая при этом возникает ошибка?

7. Если мы хотим лишь испытать возможность отмены потока с процедурой сервера, нужно ли нам устанавливать процедуру создания сервера?

8. Проверьте, что вызов door_revoke дает возможность завершиться работающим с данной процедурой потокам. Выясните, что происходит при вызове door_саll после аннулирования процедуры.

9. В нашем решении предыдущего упражнения и в листинге 15.17 мы говорим, что дескриптор двери должен быть глобальным, если он нужен процедуре сервера или процедуре создания сервера. Это утверждение, вообще говоря, неверно. Перепишите решение предыдущего упражнения, сохранив fd в качестве автоматической переменной функции main.

10. В программе листинга 15.18 мы вызывали pthread_attr_init и pthread_attr_ destroy каждый раз, когда создавался поток. Является ли такое решение оптимальным?

ГЛАВА 16