UNIX: разработка сетевых приложений
вернуться

Стивенс Уильям Ричард
Шрифт:

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

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

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

accept
одним из свободных дочерних процессов или блокировку файла или взаимного исключения. Из первых двух столбцов табл. 30.2 видно, что операционная система, в которой мы проводим измерения, осуществляет равномерную циклическую загрузку свободных процессов клиентскими соединениями.

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

child.h
, в котором определяется структура
Child
, показан в листинге 30.16.

Листинг 30.16. Структура Child

//server/child.h

1 typedef struct {

2 pid_t child_pid; /* ID процесса */

3 int child_pipefd; /* программный (неименованный) канал между

родительским и дочерним процессами */

4 int child_status; /* 0 = готово */

5 long child_count; /* количество обрабатываемых соединений */

6 } Child;

7 Child *cptr; /* массив структур Child */

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

SIGINT
и позволяет нам отслеживать распределение клиентских запросов между дочерними процессами.

Рассмотрим сначала функцию

child_make
, которая приведена в листинге 30.17. Мы создаем канал и доменный сокет Unix (см. главу 14) перед вызовом функции
fork
. После того, как создан дочерний процесс, родительский процесс закрывает один дескриптор (
sockfd[1]
), а дочерний процесс закрывает другой дескриптор (
sockfd[0]
). Более того, дочерний процесс подключает свой дескриптор канала (
sockfd[1]
) к стандартному потоку сообщений об ошибках, так что каждый дочерний процесс просто использует это устройство для связи с родительским процессом. Этот механизм проиллюстрирован схемой, приведенной на рис. 30.3.

Листинг 30.17. Функция child_make: передача дескриптора в сервере с предварительным порождением дочерних процессов

//server/child05.c

1 #include "unp.h"

2 #include "child.h"

3 pid_t

4 child_make(int i, int listenfd, int addrlen)

5 {

6 int sockfd[2];

7 pid_t pid;

8 void child_main(int, int, int);

9 Socketpair(AF_LOCAL, SOCK_STREAM, 0, sockfd);

10 if ((pid = Fork) > 0) {

11 Close(sockfd[1]);

12 cptr[i].child_pid = pid;

13 cptr[i].child_pipefd = sockfd[0];

14 cptr[i].child_status = 0;

15 return (pid); /* родительский процесс */

16 }

17 Dup2(sockfd[1], STDERR_FILENO); /* канал от дочернего процесса к

родительскому */

18 Close(sockfd[0]);

19 Close(sockfd[1]);

20 Close(listenfd); /* дочернему процессу не требуется, чтобы