UNIX: взаимодействие процессов - Уильям Стивенс

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

В тексте процедуры сервера мы сначала вызвали 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

Пакет Sun RPC

16.1. Введение

Когда мы разрабатываем приложение, мы встаем перед выбором:

1. Написать одну большую монолитную программу, которая будет делать все.

2. Разделить приложение на несколько процессов, взаимодействующих друг с другом.

Если мы выбираем второй вариант, перед нами опять встает вопрос:

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

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

Взгляните на рис. 15.1. Верхняя ситуация соответствует варианту 1, средняя — варианту 2.1, а нижняя — варианту 2.2. Большая часть этой книги посвящена обсуждению случая 2.1, то есть взаимодействию процессов в пределах одного узла с помощью таких средств IPC, как передача сообщений, разделяемая память и, возможно, некоторых форм синхронизации. Взаимодействие между потоками одного процесса или разных процессов является частным случаем этого сценария.

Когда мы выдвигаем требование поддержки возможности сетевого взаимодействия между составляющими приложения, для разработки чаще всего используется явное сетевое программирование. При этом в программе используются вызовы интерфейсов сокетов или XTI, о чем рассказывается в [24]. При использовании интерфейса сокетов клиенты вызывают функции socket, connect, read и write, а серверы вызывают socket, bind, listen, accept, read и write. Большая часть знакомых нам приложений (браузеры, серверы Web, клиенты и серверы Telnet) написаны именно так.

Альтернативным способом разработки распределенных приложений является неявное сетевое программирование. Оно осуществляется посредством удаленного вызова процедур (remote procedure call — RPC). Приложение кодируется с использованием тех же вызовов, что и обычное несетевое, но клиент и сервер могут находиться на разных узлах. Сервером называется процесс, предоставляющий другому возможность запускать одну из составляющих его процедур, а клиентом — процесс, вызывающий процедуру сервера. То, что клиент и сервер находятся на разных узлах и для связи между ними используется сетевое взаимодействие, большей частью остается скрыто от программиста. Одним из критериев оценки качества пакета RPC является именно скрытость лежащего в основе интерфейса сети.

Пример

В качестве примера использования RPC перепишем листинги 15.1 и 15.2 для использования Sun RPC вместо дверей. Клиент вызывает процедуру сервера с аргументом типа long, а возвращаемое значение представляет собой квадрат аргумента. В листинге 16.1[1] приведен текст первого файла, square.х.

//sunrpc/square1/square.x

1 struct square_in { /* входные данные (аргумент) */

2  long arg1;

3 };

4 struct square_out { /* возвращаемые данные (результат) */

5  long res1;

6 };

7 program SQUARE_PROG {

8  version SQUARE_VERS {

9   square_out SQUAREPROC(square_in) = 1; /* номер процедуры = 1 */

10  } = 1; /* номер версии */

11 } = 0x31230000; /* номер программы */

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

1-6 Мы определяем две структуры — одну для аргументов (одно поле типа long) и одну для результатов (тоже одно поле типа long).