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

6.1. Введениеы

Каждой очереди сообщений System V сопоставляется свой идентификатор очереди сообщений. Любой процесс с соответствующими привилегиями (раздел 3.5) может поместить сообщение в очередь, и любой процесс с другими соответствующими привилегиями может сообщение из очереди считать. Как и для очередей сообщений Posix, для помещения сообщения в очередь System V не требуется наличия подключенного к ней на считывание процесса.

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

struct msqid_ds {
 struct ipc_perm msg_perm; /* Разрешения чтения и записи: раздел 3.3 */
 struct msg *msg_first; /* указатель на первое сообщение в очереди */
 struct msg *msg_last; /* указатель на последнее сообщение в очереди */
 msglen_t msg_cbytes; /* размер очереди в байтах */
 msgqnum_t msg_qnum;  /* количество сообщений в очереди */
 msglen_t msg_qbytes; /* максимальный размер очереди в байтах */
 pid_t msg_lspid;  /* идентификатор (pid) последнего процесса, вызвавшего msgsnd(); */
 pid_t msg_lrpid;  /* pid последнего msgrcv(); */
 time_t msg_stime; /* время отправки последнего сообщения */
 time_t msg_rtime; /* время последнего считывания сообщения */
 time_t msg_ctime; /* время последнего вызова msgctl(), изменившего одно из полей структуры */
};

ПРИМЕЧАНИЕ

Unix 98 не требует наличия полей msg_first, msg_last и msg_cbytes. Тем не менее они имеются в большинстве существующих реализаций, производных от System V. Естественно, ничто не заставляет реализовывать очередь сообщений через связный список, который неявно предполагается при наличии полей msg_first и msg_last. Эти два указателя обычно указывают на участки памяти, принадлежащие ядру, и практически бесполезны для приложения.

Мы можем изобразить конкретную очередь сообщений, хранимую ядром как связный список, — рис. 6.1. В этой очереди три сообщения длиной 1, 2 и 3 байта с типами 100, 200 и 300 соответственно.

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

Рис. 6.1. Структура очереди system V в ядре

6.2. Функция msgget

Создать новую очередь сообщений или получить доступ к существующей можно с помощью функции msgget:

#include 
int msgget(key_t key, int oflag);
/* Возвращает неотрицательный идентификатор в случае успешного завершения, –1 в случае ошибки */

Возвращаемое значение представляет собой целочисленный идентификатор, используемый тремя другими функциями msg для обращения к данной очереди. Идентификатор вычисляется на основе указанного ключа, который может быть получен с помощью функции ftok или может представлять собой константу IPC_PRIVATE, как показано на рис. 3.1.

Флаг oflag представляет собой комбинацию разрешений чтения-записи, показанную в табл. 3.3. К разрешениям можно добавить флаги IPC_CREAT или IPC_CREAT | IPC_EXCL с помощью логического сложения, как уже говорилось в связи с рис. 3.2.

При создании новой очереди сообщений инициализируются следующие поля структуры msqid_ds:

■ полям uid и cuid структуры msg_perm присваивается значение действующего идентификатора пользователя вызвавшего процесса, а полям gid и cgid — действующего идентификатора группы;

■ разрешения чтения-записи, указанные в oflag, помещаются в msg_perm.mode;

■ значения msg_qnum, msg_lspid, msg_lrpid, msg_stime и msg_rtime устанавливаются в 0;

■ в msg_ctime записывается текущее время;

■ в msg_qbytes помещается системное ограничение на размер очереди.

6.3. Функция msgsnd

После открытия очереди сообщений с помощью функции msgget можно помещать сообщения в эту очередь с помощью msgsnd.

#include 
int msgsnd(int msqid, const void *ptr, size_t length, int flag); 
/* Возвращает 0 в случае успешного завершения; –1 – в случае ошибки */

Здесь msqid представляет собой идентификатор очереди, возвращаемый msgget. Указатель ptr указывает на структуру следующего шаблона, определенного в :

struct msgbuf {
 long mtype; /* тип сообщения, должен быть > 0 */
 char mtext[1]; /* данные */
};

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

Название mtext в структуре msgbuf употреблено не вполне правильно; данные в сообщении совсем не обязательно должны быть текстом. Разрешена передача любых типов данных как в двоичном, так и в текстовом формате. Ядро никак не интерпретирует содержимое сообщения.

Для описания структуры мы используем термин «шаблон», поскольку ptr указывает на целое типа long, представляющее собой тип сообщения, за которым непосредственно следует само сообщение (если его длина больше 0 байт). Большинство приложений не пользуются этим определением структуры msgbuf, поскольку установленного в ней количества данных (1 байт) обычно недостаточно для прикладных задач. На количество данных в сообщении никаких ограничений при компиляции не накладывается (как правило, оно может быть изменено системным администратором), поэтому вместо объявления структуры с большим объемом данных (большим, чем поддерживается текущей реализацией) определяется этот шаблон. Большинство приложений затем определяют собственную структуру сообщений, в которой передаваемые данные зависят от нужд этих приложений.

Например, если приложению нужно передавать сообщения, состоящие из 16-разрядного целого, за которым следует 8-байтовый массив символов, оно может определить свою собственную структуру так:

#define MY_DATA 8
typedef struct my_msgbuf {
 long mtype; /* тип сообщения */
 int16_t mshort; /* начало данных */
 char mchar[MY_DATA]; 
} Message;

Аргумент length функции msgsnd указывает длину сообщения в байтах. Это длина пользовательских данных, следующих за типом сообщения (целое типа long). Длина может быть и 0. В указанном выше примере длина может быть вычислена как sizeof(Message) – sizeof(long).

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

■ в данной очереди уже имеется слишком много данных (значение msg_qbytes в структуре msqid_ds);

■ во всей системе имеется слишком много сообщений.

Если верно одно из этих условий и установлен флаг IPC_NOWAIT, функция msgsnd возвращает ошибку с кодом EAGAIN. Если флаг IPC_NOWAIT не указан, а одно из этих условий выполняется, поток приостанавливается до тех пор, пока не произойдет одно из следующего:

■ для сообщения освободится достаточно места;

■ очередь с идентификатором msqid будет удалена из системы (в этом случае возвращается ошибка с кодом EIDRM);

■ вызвавший функцию поток будет прерван перехватываемым сигналом (в этом случае возвращается ошибка с кодом EINTR).

6.4. Функция msgrcv

Сообщение может быть считано из очереди с помощью функции msgrcv.

#include 
ssize_t msgrcv(int msqid, void *ptr, size_t length, long type, int flag);
/* Возвращает количество данных в сообщении, –1 – в случае ошибки */

Аргумент ptr указывает, куда следует помещать принимаемые данные. Как и для msgsnd, он указывает на поле данных типа long (рис. 4.13), которое непосредственно предшествует полезным данным.

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

Аргумент type определяет тип сообщения, которое нужно считать из очереди:

■ если значение type равно 0, возвращается первое сообщение в очереди (то есть при указании типа 0 возвращается старейшее сообщение);

■ если тип больше 0, возвращается первое сообщение, тип которого равен указанному;

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

Рассмотрим пример очереди сообщений, изображенный на рис. 6.1. В этой очереди имеются три сообщения:

■ первое сообщение имеет тип 100 и длину 1;

■ второе сообщение имеет тип 200 и длину 2;

■ третье сообщение имеет тип 300 и длину 3.

Таблица 6.1 показывает, какое сообщение будет возвращено при различных значениях аргумента type.

Таблица 6.1. Возвращаемое сообщение в зависимости от аргумента type 

type	Тип возвращаемого сообщения
0	100
100	100
200	200
300	300
-100	100
-200	100
-300	100

Аргумент flag указывает, что делать, если в очереди нет сообщения с запрошенным типом. Если установлен бит IPC_NOWAIT, происходит немедленный возврат из функции msgrcv с кодом ошибки ENOMSG. В противном случае вызвавший процесс блокируется до тех пор, пока не произойдет одно из следующего:

■ появится сообщение с запрошенным типом;

■ очередь с идентификатором msqid будет удалена из системы (в этом случае будет возвращена ошибка с кодом EIDRM);

■ вызвавший поток будет прерван перехватываемым сигналом (в этом случае возвращается ошибка EINTR).

В аргументе flag можно указать дополнительный бит MSG_NOERROR. При установке этого бита данные, превышающие объем буфера (аргумент length), будут просто обрезаться до его размера без возвращения кода ошибки. Если этот флаг не указать, при превышении объемом сообщения аргумента length будет возвращена ошибка E2BIG.

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

6.5. Функция msgctl

Функция msgctl позволяет управлять очередями сообщений:

#include 
int msgctl(int msqid, int cmd, struct msqid_ds *buff);
/* Возвращает 0 в случае успешного завершения, –1 в случае ошибки */

Команд (аргумент cmd) может быть три:

■ IPC_RMID — удаление очереди с идентификатором msqidиз системы. Все сообщения, имеющиеся в этой очереди, будут утеряны. Мы уже видели пример действия этой функции в листинге 3.2. Для этой команды третий аргумент функции игнорируется.

■ IPC_SET — установка значений четырех полей структуры msqid_ds данной очереди равными значениям соответствующих полей структуры, на которую указывает аргумент buff: msg_perm.uid, msg_perm.gid, msg_perm.mode, msg_qbytes.

■ IPC_STAT — возвращает вызвавшему процессу (через аргумент buff) текущее содержимое структуры msqid_ds для указанной очереди.

Пример

Программа в листинге 6.1 создает очередь сообщений, помещает в нее сообщение с 1 байтом информации, вызывает функцию msgctl с командой IPC_STAT, выполняет команду ipcs, используя функцию system, а затем удаляет очередь, вызвав функцию msgctl с командой IPC_RMID.

Листинг 6.1.[1] Пример использования функции msgctl с командой IPC_STAT

//svmsg/ctl.с
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int msqid;
6   struct msqid_ds info;
7   struct msgbuf buf;
8   msqid = Msgget(IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);
9   buf.mtype = 1;
10  buf.mtext[0] = 1;
11  Msgsnd(msqid, &buf, 1, 0);
12  Msgctl(msqid, IPC_STAT, &info);
13  printf("read-write: *03o, cbytes = %lu, qnum = %lu, qbytes = %lu\n",
14   info.msg_perm.mode & 0777, (ulong_t) info.msg_cbytes,
15   (ulong_t) info.msg_qnum, (ulong_t) info.msg_qbytes);
16  system("ipcs –q");
17  Msgctl(msqid, IPC_RMID, NULL);
18  exit(0);
19 }

Мы собираемся отправить сообщение размером 1 байт, поэтому можно просто воспользоваться стандартным определением структуры msgbuf из . Выполнение этой программы приведет к следующему результату:

solaris %ctl
read-write: 664, cbytes = 1, qnum = 1, qbytes = 4096
IPC status from  as of MOn Oct 20 15:36:49 1997
T ID   Key      MODE       OWNER    GROUP
Message Queues:
q 1150 00000000 –rw-rw-r-- rstevens other1

Выведенные значения соответствуют ожидаемым. Нулевое значение ключа обычно соответствует IPC_PRIVATE, как мы отмечали в разделе 3.2. В этой системе на очередь сообщений накладывается ограничение по объему в 4096 байт. Поскольку мы записали сообщение с 1 байтом данных и msg_cbytes имеет значение 1, это ограничение накладывается на объем полезных данных и не включает тип сообщения (long), указываемый для каждого сообщения.

6.6. Простые примеры

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

Программа msgcreate

В листинге 6.2 приведена программа msgcreate, создающая очередь сообщений.

9-12 Параметр командной строки –e позволяет указать флаг IPC_EXCL.

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

Листинг 6.2. Создание очереди сообщений System V

//svmsg/msgcreate.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int c, oflag, mqid;
6   oflag = SVMSG_MODE | IPC_CREAT;
7   while ((c = Getopt(argc, argv, "e")) != –1) {
8    switch (c) {
9    case 'e':
10    oflag |= IPC_EXCL;
11    break;
12   }
13  }
14  if (optind != argc – 1)
15   err_quit("usage: msgcreate [ –e ] ");
16  mqid = Msgget(Ftok(argv[optind], 0), oflag);
17  exit(0);
18 }

Программа msgsnd

Программа msgsnd приведена в листинге 6.3. Она помещает в очередь одно сообщение заданной длины и типа.

Мы создаем указатель на структуру msgbuf общего вида, а затем выделяем место под реальную структуру (буфер записи) соответствующего размера, вызвав calloc. Эта функция инициализирует буфер нулем.

Листинг 6.3. Помещение сообщения в очередь System V

//svmsg/msgsnd.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int mqid;
6   size_t len;
7   long type;
8   struct msgbuf *ptr;
9   if (argc != 4)
10   err_quit("usage: msgsnd <#bytes>");
11  len = atoi(argv[2]);
12  type = atoi(argv[3]);
13  mqid = Msgget(Ftok(argv[1], 0), MSG_W);
14  ptr = Calloc(sizeof(long) + len, sizeof(char));
15  ptr->mtype = type;
16  Msgsnd(mqid, ptr, len, 0);
17  exit(0);
18 }

Программа msgrcv

В листинге 6.4 приведен текст программы msgrcv, считывающей сообщение из очереди. В командной строке может быть указан параметр –n, отключающий блокировку, а параметр –t может быть использован для указания типа сообщения в функции msgrcv.

2 Не существует простого способа определить максимальный размер сообщения (об этом и других ограничениях мы поговорим в разделе 6.10), поэтому мы определим свою собственную константу.

Листинг 6.4. Считывание сообщения из очереди System V

//svmsg/msgrcv.c
1  #include "unpipc.h"
2  #define MAXMSG (8192 + sizeof(long))

3  int
4  main(int argc, char **argv)
5  {
6   int c, flag, mqid;
7   long type;
8   ssize_t n;
9   struct msgbuf *buff;
10  type = flag = 0;
11  while ((c = Getopt(argc, argv, "nt:")) != –1) {
12   switch (c) {
13   case 'n':
14    flag |= IPC_NOWAIT;
15    break;
16   case 't':
17    type = atol(optarg);
18    break;
19   }
20  }
21  if (optind != argc – 1)
22   err_quit("usage: msgrcv [ –n ] [ –t type ] ");
23  mqid = Msgget(Ftok(argv[optind], 0), MSG_R);
24  buff = Malloc(MAXMSG);
25  n = Msgrcv(mqid, buff, MAXMSG, type, flag);
26  printf("read %d bytes, type = %ld\n", n, buff->mtype);
27  exit(0);
28 }

Программа msgrmid

Для удаления очереди сообщений мы вызываем функцию msgctl с командой IPC_RMID, как показано в листинге 6.5.

Листинг 6.5. Удаление очереди сообщений System V

//svmsg/msgrmid.c
1  #include "unpipc.h"

2  int
3  main(int argc, char **argv)
4  {
5   int mqid;
6   if (argc != 2)
7    err_quit("usage: msgrmid ");
8   mqid = Msgget(Ftok(argv[1], 0), 0);
9   Msgctl(mqid, IPC_RMID, NULL);
10  exit(0);
11 }

Примеры

Теперь воспользуемся четырьмя только что написанными программами. Создадим очередь и поместим в нее три сообщения:

solaris % msgcreate /tmp/no/such/file
ftok error for pathname "tmp/no/such/file" and id 0: No such file or directory
solaris % touch /trap/test1
solaris % msgcreate /tmp/test1
solaris % msgsnd /tmp/test1 1 100
solaris % msgsnd /tmp/test1 2 200
solaris % msgsnd /tmp/test1 3 300
solaris % ipcs –qo
IPC status from as of Sat Jan 10 11:25:45 1998
T ID  KEY        MODE       OWNER    GROUP  CBYTES QNUM
Message Queues:
q 100 0х0000113e –rw-r--r-- rstevens other1 6      3

Сначала мы пытаемся создать очередь, используя имя несуществующего файла. Пример показывает, что файл, указываемый в качестве аргумента ftok, обязательно должен существовать. Затем мы создаем файл /tmp/test1 и используем его имя при создании очереди сообщений. После этого в очередь помещаются три сообщения длиной 1, 2 и 3 байта со значениями типа 100, 200 и 300 (вспомните рис. 6.1). Программа ipcs показывает, что в очереди находятся 3 сообщения общим объемом 6 байт.

Теперь продемонстрируем использование аргумента type при вызове msgrcv для считывания сообщений в произвольном порядке:

solaris % msgrcv –t 200 /tmp/test1
read 2 bytes, type = 200
solaris % msgrcv –t -300 /tmp/test1
read 1 bytes, type = 100
solaris % msgrcv /tmp/test1
read 3 bytes, type = 300
solaris % msgrcv –n /tmp/test1
msgrcv error: No message of desired type

В первом примере запрашивается сообщение с типом 200, во втором примере — сообщение с наименьшим значением типа, не превышающим 300, а в третьем — первое сообщение в очереди. Последний запуск msgrcv иллюстрирует действие флага IPC_NOWAIT.

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

solaris % ipcs –qo
IPC status from  as of Sat Jan 10 11:37:01 1998
T ID  KEY        MODE       OWNER    GROUP  CBYTES QNUM
Message Queues:
q 100 0x0000113e –rw-r--r-- rstevens other1 0      0
solaris % msgsnd /tmp/test1 1 100
solaris % msgrcv –t 999 /temp/test1
^? нажали клавишу прерывания выполнения программы
solaris % msgrcv –n –t999/tmp/test1
msgrcv error: No message of desired type
solaris % grep desired /usr/include/sys/errno.h
#define ENOMSG 35 /* No message of desired type */
solaris % msgrmid /tmp/test1

Сначала мы вызываем ipcs, чтобы убедиться, что очередь пуста, а затем помещаем в нее сообщение длиной 1 байт с типом 100. Затем мы запрашиваем сообщение с типом 999, и программа блокируется (при вызове msgrcv), ожидая помещения в очередь сообщения с указанным типом. Мы прерываем ожидание нажатием клавиши. Затем мы запускаем программу с флагом –n, предотвращающим блокировку, и видим, что в этом случае возвращается ошибка с кодом ENOMSG. После этого мы удаляем очередь с помощью программы msgrmid. Мы могли бы удалить очередь и с помощью системной команды

solaris % ipcrm –q 100

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

solaris % ipcrm –Q 0x113e

где указывается ключ очереди сообщений.

Программа msgrcvid

Покажем теперь, что для получения доступа к очереди сообщений System V не обязательно вызывать msgget: все, что нужно, — это знать идентификатор очереди сообщений, который легко получить с помощью ipcs, и считать разрешения доступа для очереди. В листинге 6.6 приведен упрощенный вариант программы msgrcv из листинга 6.4.

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

Листинг 6.6. Считывание из очереди сообщений System V с известным идентификатором

//svmsg/msgrcvid.c
1  #include "unpipc.h"
2  #define MAXMSG (8192 + sizeof(long))

3  int
4  main(int argc, char **argv)
5  {
6   int mqid;
7   ssize_t n;
8   struct msgbuf *buff;
9   if (argc != 2)
10   err_quit("usage: msgrcvid ");
11  mqid = atoi(argv[1]);
12  buff = Maloc(MAXMSG);
13  n = Msgrcv(mqid, buff, MAXMSG, 0, 0);
14  printf("read %d bytes, type = %ld\n", n, buff->mtype);
15  exit(0);
16 }

Вот пример использования этой программы:

solaris % touch /tmp/testid
solaris % msgcreate /tmp/testid
solaris % msgsnd /tmp/testid4 400
solaris % ipcs –qo
IPC status from  as of Wed Mar 25 09:48:28 1998
T ID  KEY        MODE       OWNER    GROUP  CBYTES QNUM
Message Queues:
q 150 0x0000118a –rw-r--r-- rstevens other1 4      1
solaris % msgrcvid 150
read 4 bytes, type = 400

Идентификатор очереди (150) мы узнали с помощью ipcs, его мы и предоставляем программе msgrcvid в качестве аргумента командной строки.

Этот же метод можно использовать для семафоров System V (упражнение 11.1) и разделяемой памяти System V (упражнение 14.1).

6.7. Пример программы клиент-сервер

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

Заголовочный файл svmsg.h приведен в листинге 6.7. Мы подключаем наш стандартный заголовочный файл и определяем ключи для каждой из очередей сообщений.

Листинг 6.7. Заголовочный файл svmsg.h для программы клиент-сервер, использующей очереди сообщений

//svmsgcliserv/svmsg.h
1 #include "unpipc.h"
2 #define MQ_KEY1 1234L
3 #define MQ_KEY2 2345L

Функция main для сервера приведена в листинге 6.8. Программа создает обе очереди сообщений, и не беда, если какая-нибудь из них уже существует, потому что мы не указываем флаг IPC_EXCL. Функция server дана в листинге 4.16. Она вызывает наши собственные функции mesgsend и mesgrecv, новые версии которых будут приведены ниже.

Листинг 6.8. Функция main программы-сервера, использующей очереди сообщений

//svmsgcliserv/server_main.с
1  #include "svmsg.h"

2  void server(int, int);
3  int
4  main(int argc, char **argv)
5  {
6   int readid, writeid;
7   readid = Msgget(MQ_KEY1, SVMSG_MODE | IPC_CREAT);
8   writeid = Msgget(MQ_KEY2, SVMSG_MODE | IPC_CREAT);
9   server(readid, writeid);
10  exit(0);
11 }

Листинг 6.9. Функция main программы-клиента, использующей очереди сообщений

//svmsgcliserv/client_main.с
1  #include "svmsg.h"
2  void client(int, int);

3  int
4  main(int argc, char **argv)
5  {
6   int readid, writeid;
7   /* assumes server has created the queues */
8   writeid = Msgget(MQ_KEY1, 0);
9   readid = Msgget(MQ_KEY2, 0);
10  client(readid, writeid);
11  /* now we can delete the queues */
12  Msgctl(readid, IPC_RMID. NULL);
13  Msgctl(writeid, IPC_RMID, NULL);
14  exit(0);
15 }

В листинге 6.9 приведен текст функции main программы-клиента. Программа открывает две очереди сообщений и вызывает функцию client из листинга 4.15. Эта функция использует две другие: mesg_send и mesg_recv, которые будут приведены ниже.

И функция client, и функция server используют формат сообщений, изображенный в листинге 4.12. Для передачи и приема сообщений они используют функции mesg_send и mesg_recv. Старые версии этих функций, приведенные в листингах 4.13 и 4.14, вызывали write и read и работали с программными каналами и FIFO, так что нам придется переписать их для использования очередей сообщений. В листингах 6.10 и 6.11 приведены новые версии этих функций. Обратите внимание, что аргументы функций не изменились, поскольку первый целочисленный аргумент может содержать как целочисленный дескриптор программного канала или FIFO, так и целочисленный дескриптор очереди сообщений.

Листинг 6.10. Функция mesg_send, работающая с очередью сообщений System V

//svmsgcliserv/mesg_send.с
1 #include "mesg.h"

2 ssize_t
3 mesg_send(int id, struct mymesg *mptr)
4 {
5  return(msgsnd(id, &(mptr->mesg_type), mptr->mesg_len, 0));
6 }

Листинг 6.11. Функция mesg_recv, работающая с очередью сообщений System V

//svmsgcliserv/mesg_recv.с
1 #include "mesg.h"

2 ssize_t
3 mesg_recv(int id, struct mymesg *mptr)
4 {
5  ssize_t n;
6  n = msgrcv(id, &(mptr->mesg_type), MAXMESGDATA, mptr->mesg_type, 0);
7  mptr->mesg_len = n; /* количество возвращаемых данных */
8  return(n); /* –1 в случае ошибки, 0 – конец файла, иначе – >0 */
9 }

6.8. Мультиплексирование сообщений

Наличие поля type у каждого сообщения в очереди предоставляет две интересные возможности:

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

2. Поле type может использоваться для установки приоритета сообщений. Это позволяет получателю считывать сообщения в порядке, отличном от обычного для очередей (FIFO). В программных каналах и FIFO данные могли приниматься только в том порядке, в котором они были отправлены. Очереди System V позволяют считывать сообщения в произвольном порядке в зависимости от значений типа сообщений. Более того, можно вызывать msgrcv с флагом IPC_NOWAIT для считывания сообщений с конкретным типом и немедленного возвращения управления процессу в случае отсутствия таких сообщений.

Пример: одна очередь на приложение

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

Рис. 6.2. Мультиплексирование сообщений между несколькими клиентами и одним сервером

Рассмотрим усложненный вариант: один сервер и несколько клиентов. В этом случае можно использовать значение типа 1, например, для обозначения сообщений от любого клиента серверу. Если клиент передаст серверу свой идентификатор процесса в качестве части сообщения, сервер сможет отсылать клиенту сообщения, используя его идентификатор в качестве значения типа сообщения. Каждый клиент будет использовать свой PID в качестве аргумента type при вызове msgrcv. На рис. 6.2 приведен пример использования очереди для мультиплексирования этих сообщений между несколькими клиентами и одним сервером.

ПРИМЕЧАНИЕ

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

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

В листинге 6.12 приведен текст функции main сервера. Заголовочный файл svmsg.h был приведен в листинге 6.7. Создается единственная очередь сообщений (если она существует, ошибки не возникнет). Идентификатор этой очереди сообщений используется в качестве обоих аргументов при вызове функции server.

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

//svmsgmpx1q/server_main.с
1  #include "svmsg.h"
2  void server(int, int);

3  int
4  main(int argc, char **argv)
5  {
6   int msqid;
7   msqid = Msgget(MQ_KEY1, SVMSG_MODE | IPC_CREAT);
8   server(msqid, msqid); /* одна очередь в обе стороны */
9   exit(0);
10 }

Функция server обеспечивает работу сервера. Ее текст приведен в листинге 6.13. Эта функция представляет собой комбинацию листинга 4.10 — нашего сервера FIFO, считывавшего команды, состоявшие из идентификатора процесса и полного имени файла, — и листинга 4.16, в котором использовались функции mesg_send и mesg_recv. Обратите внимание, что идентификатор процесса, отправляемый клиентом, используется в качестве типа для всех сообщений, отправляемых сервером этому клиенту. Эта функция представляет собой бесконечный цикл, в котором считываются запросы клиентов и отсылаются запрошенные файлы. Этот сервер является последовательным (см. раздел 4.9).

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

Функция client, текст которой дан в листинге 6.15, обеспечивает всю обработку со стороны клиента. Эта функция представляет собой комбинацию программ из листингов 4.11 и 4.15. В первой программе клиент отсылал свой идентификатор и полное имя файла, а во второй программе использовались функции mesg_send и mesg_recv. Обратите внимание, что тип сообщений, запрашиваемых функцией mesg_recv, совпадает с идентификатором процесса клиента.

Функции client и server используют функции mesg_send и mesg_recv из листингов 6.9 и 6.11.

Листинг 6.13. Функция server

//svmsgmpx1q/server.c
1  #include "mesg.h"

2  void
3  server(int readfd, int writefd)
4  {
5   FILE *fp;
6   char *ptr;
7   pid_t pid;
8   ssize_t n;
9   struct mymesg mesg;
10  for (;;) {
11   /* считывание полного имени из канала IPC */
12   mesg.mesg_type = 1:
13   if ((n = Mesg_recv(readfd, &mesg)) == 0) {
14    err_msg("pathname missing");
15    continue;
16   }
17   mesg.mesg_data[n] = '\0'; /* полное имя */
18   if ((ptr = strchr(mesg.mesg_data, ' ')) == NULL) {
19    err_msg("bogus request: %s", mesg.mesg_data);
20    continue;
21   }
22   *ptr++ =0; /* ptr = полное имя */
23   pid = atol(mesg.mesg_data);
24   mesg.mesg_type = pid; /* для обратных сообщений */
25   if ((fp = fopen(ptr, "r")) == NULL) {
26    /* 4error: must tell client */
27    snprintf(mesg.mesg_data + n, sizeof(mesg.mesg_data) – n,
28     ": can't open. %s\n", strerror(errno));
29    mesg.mesg_len – strlen(ptr);
30    memmove(mesg.mesg_data, ptr, mesg.mesg_len);
31    Mesg_send(writefd, &mesg);
32   } else {
33    /* файл открыт, копируем клиенту */
34    while (Fgets(mesg.mesg_data, MAXMESGDATA, fp) != NULL) {
35     mesg.mesg_len = strlen(mesg.mesg_data);
36     Mesg_send(writefd, &mesg);
37    }
38    Fclose(fp);
39   }
40   /* сообщение нулевой длины заканчивает связь */
41   mesg.mesg_len = 0;
42   Mesg_send(writefd, &mesg);
43  }
44 }

Листинг 6.14. Функция main клиента

//svmsgmpx1q/client_main.c
1  #include "svmsg.h"
2  void client(int, int);

3  int
4  main(int argc, char **argv)
5  {
6   int msqid;
7   /* сервер должен был создать очередь */
8   msqid = Msgget(MQ_KEY1, 0);
9   client(msqid, msqid); /* одна очередь в обе стороны */
10  exit(0);
11 }

Листинг 6.15. Функция client

//svmsgmpx1q/client.с
1  #include "mesg.h"

2  void
3  client(int readfd, int writefd)
4  {
5   size_t len;
6   ssize_t n;
7   char *ptr;
8   struct mymesg mesg;
9   /* инициализируем буфер идентификатором процесса и пробелом */
10  snprintf(mesg.mesg_data, MAXMESGDATA. "%ld ", (long) getpid());
11  len = strlen(mesg.mesg_data);
12  ptr = mesg.mesg_data + len;
13  /* считываем полное имя файла */
14  Fgets(ptr, MAXMESGDATA – len, stdin);
15  len = strlen(mesg.mesg_data);
16  if (mesg.mesg_data[len-1] == '\n')
17   len--; /* удаляем перевод строки fgets() */
18  mesg.mesg_len = len;
19  mesg.mesg_type = 1;
20  /* записываем PID и имя файла в канал IPC */
21  Mesg_send(writefd, &mesg);
22  /* считываем из канала IPC, записываем в stdout */
23  mesg.mesg_type = getpid();
24  while ((n = Mesg_recv(readfd, &mesg)) > 0)
25   Write(STDOUT_FILENO, mesg.mesg_data, n);
26 }

Пример: одна очередь для каждого клиента

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

Рис. 6.3. Одна очередь для сервера и по одной для каждого клиента

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

ПРИМЕЧАНИЕ

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

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

■ mesg.h (листинг 4.12);

■ svmsg.h (листинг 6.7);

■ функция main сервера (листинг 6.12);

■ функция mesg_send (листинг 4.13).

Функция main клиента приведена в листинге 6.16; она слегка изменилась по сравнению с листингом 6.14. Мы открываем очередь сервера с известным ключом (MQ_KEY1) и создаем нашу собственную очередь с ключом IPC_PRIVATE. Два идентификатора этих очередей становятся аргументами функции client (листинг 6.17). После завершения работы клиента его персональная очередь удаляется.

Листинг 6.16. Функция main клиента

//svmsgmpxnq/client_main.с
1  #include "svmsg.h"

2  void client(int, int);
3  int
4  main(int argc, char **argv)
5  {
6   int readid, writeid;
7   /* сервер должен создать свою очередь */
8   writeid = Msgget(MQ_KEY1, 0);
9   /* мы создаем свою собственную очередь */
10  readid = Msgget(IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);
11  client(readid, writeid);
12  /* и удаляем нашу собственную очередь */
13  Msgctl(readid, IPC_RMID, NULL);
14  exit(0);
15 }

Листинг 6.17. Функция client

//svmsgmpxnq/client.с
1  #include "mesg.h"

2  void
3  client(int readid, int writeid)
4  {
5   size_t len;
6   ssize_t n;
7   char *ptr;
8   struct mymesg mesg;
9   /* инициализируем буфер идентификатором очереди и пробелом */
10  snprintf(mesg.mesg_data, MAXMESGDATA, "%d ", readid);
11  len = strlen(mesg.mesg_data);
12  ptr = mesg.mesg_data + len;
13  /* считываем имя файла */
14  Fgets(ptr, MAXMESGDATA – len, stdin);
15  len = strlen(mesg.mesg_data);
16  if (mesg.mesg_data[len-1] == '\n')
17   len--; /* удаляем перевод строки fgets() */
18  mesg.mesg_len = len;
19  mesg.mesg_type = 1;
20  /* отправляем идентификатор очереди и имя файла серверу */
21  Mesg_send(writeid, &mesg);
22  /* считываем ответ из нашей очереди и записываем его в stdout */
23  while ((n = Mesg_recv(readid, &mesg)) > 0)
24   Write(STDOUT_FILENO, mesg.mesg_data, n);
25 }

В листинге 6.17 приведен текст функции client. Эта функция практически идентична функции из листинга 6.15, но вместо передачи идентификатора процесса клиента на сервер направляется идентификатор очереди клиента. Тип сообщения в структуре mesg остается равным 1, поскольку это значение устанавливается для сообщений, передаваемых в обе стороны.

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

Установка обработчика сигнала для SIGCHLD

10 Поскольку для каждого клиента порождается отдельный процесс, нужно позаботиться о процессах-зомби. В разделах 5.9 и 5.10 [24] об этом говорится подробно. Здесь мы просто установим обработчик для сигнала SIGCHLD, и наша функция sig_chld (листинг 6.18) будет вызываться при завершении работы дочернего процесса.

12-18 Породивший процесс сервера блокируется в вызове mesg_recv, ожидая появления сообщения от очередного клиента.

25-45 Вызовом fork порождается новый процесс, который производит попытку открыть запрошенный файл и отправляет клиенту либо сообщение об ошибке, либо содержимое файла. Мы преднамеренно поместили вызов fopen в дочерний процесс, а не в родительский, поскольку если файл находится в удаленной файловой системе, его открытие может занять довольно много времени в случае наличия проблем с сетью.

Функция-обработчик для SIGCHLD приведена в листинге 6.18. Она скопирована с листинга 5.11 [24].

Листинг 6.18. Обработчик сигнала SIGCHLD, вызывающий waitpid

//svmsgmpxnq/sigchldwaitpid.с
1 #include "unpipc.h"

2 void
3 sig_chld(int signo)
4 {
5  pid_t pid;
6  int stat;
7  while ((pid = waitpid(-1, &stat, WNOHANG)) > 0);
8  return;
9 }

Каждый раз при вызове обработчика происходит циклический вызов waitpid для получения статуса завершения работы всех дочерних процессов, которые могли завершить работу. Затем происходит возврат из обработчика сигнала. При этом может возникнуть проблема, поскольку родительский процесс проводит большую часть времени в заблокированном состоянии (при вызове mesg_recv, листинг 6.9). При возвращении из обработчика этот вызов msgrcv прерывается. Функция возвращает ошибку с кодом EINTR, как рассказывается в разделе 5.9 [24]. 

Нам нужно обработать такой возврат из вызванной функции, поэтому мы пишем новую функцию-обертку Mesg_recv, приведенную в листинге 6.20. Эта программа допускает возвращение ошибки с кодом EINTR функцией mesg_recv (которая просто вызывает msgrcv), и, если это происходит, мы просто еще раз вызываем mesg_recv.

Листинг 6.19. Функция server

//svmsgmpxnq/server.c
1  #include "mesg.h"

2  void
3  server(int readid, int writeid)
4  {
5   FILE *fp;
6   char *ptr;
7   ssize_t n;
8   struct mymesg mesg;
9   void sig_chld(int);
10  Signal(SIGCHLD, sig_chld);
11  for (;;) {
12   /* считывание имени файла из очереди */
13   mesg.mesg_type = 1;
14   if ((n = Mesg_recv(readid, &mesg)) == 0) {
15    err_msg("pathname missing");
16    continue;
17   }
18   mesg.mesg_data[n] = 40'; /* имя файла */
19   if ((ptr = strchr(mesg.mesg_data, ' ')) = NULL) {
20    err_msg("bogus request: %s", mesg.mesg_data);
21    continue;
22   }
23   *ptr++ = 0; /* ptr = имя файла */
24   writeid = atoi(mesg.mesg_data);
25   if (Fork() == 0) { /* дочерний процесс */
26    if ((fp = fopen(ptr, "r")) == NULL) {
27     /* ошибка: нужно сообщить клиенту */
28     snprintf(mesg.mesg_data + n, sizeof(mesg.mesg_data) – n,
29      ": can't open, %s\n", strerror(errno));
30     mesg.mesg_len = strlen(ptr);
31     memmove(mesg.mesg_data, ptr, mesg.mesg_len);
32     Mesg_send(writeid, &mesg);
33    } else {
34     /* файл открыт, копируем клиенту */
35     while (Fgets(mesg.mesg_data, MAXMESGDATA, fp) != NULL) {
36      mesg.mesg_len = strlen(mesg.mesg_data);
37      Mesg_send(writeid, &mesg);
38     }
39     Fclose(fp);
40    }
41    /* отправка сообщения нулевой длины, указывающего конец файла */
42    mesg.mesg_len = 0;
43    Mesg_send(writeid, &mesg);
44    exit(0); /* завершение дочернего процесса */
45   }
46   /* родительский процесс просто зациклен */
47  }
48 }

Листинг 6.20. Функция-обертка Mesg_recv, обрабатывающая прерванный системный вызов

//svmsgmpxnq/mesg_recv.с
10 ssize_t
11 Mesg_recv(int id, struct mymesg *mptr)
12 {
13  ssize_t n;
14  do {
15   n = mesg_recv(id, mptr);
16  } while (n == –1 && errno == EINTR);
17  if (n == –1)
18   err_sys("mesg_recv error");
19  return(n);
20 }

6.9. Использование select и poll с очередями сообщений

Одним из недостатков очередей сообщений System V является то, что они идентифицируются не дескрипторами, а идентификаторами. Поэтому с ними нельзя использовать функции select и poll (глава 6 [24]).

ПРИМЕЧАНИЕ

На самом деле одна из версий Unix, а именно AIX (созданная IBM), позволяет использовать select с очередями сообщений System V, а не только с дескрипторами. Но эта возможность имеется только в AIX.

Этот недостаток часто всплывает, когда возникает необходимость написать сервер, работающий одновременно с сетевыми соединениями и с IPC. Сетевые соединения с использованием интерфейса сокетов или XTI ([24]) используют дескрипторы, что позволяет вызывать select или poll. Программные каналы и FIFO также идентифицируются дескрипторами, поэтому для них тоже допустимо использование этих функций.

Одним из решений этой проблемы является следующее: сервер должен создать канал и породить процесс, который будет заблокирован при вызове msgrcv. При получении сообщения произойдет возврат из msgrcv, дочерний процесс получит это сообщение из очереди и запишет его в канал. Затем родительский процесс может использовать функцию select для канала совместно с сетевыми соединениями. Недостаток этого подхода в том, что сообщения обрабатываются трижды: при считывании дочерним процессом с помощью msgrcv, при отправке в канал и при считывании из канала родительским процессом. Для ускорения обработки порожденный процесс может создать сегмент совместно используемой с породившим процессом памяти, а канал использовать как флаг (упражнение 12.5).

ПРИМЕЧАНИЕ

В листинге 5.12 мы привели решение с использованием очередей сообщений Posix, которое не требовало вызова fork. Для очередей сообщений Posix можно было обойтись одним процессом, поскольку они предусматривают уведомление о появлении нового сообщения с помощью сигнала. Для очередей System V такая возможность не предусмотрена, поэтому приходится порождать процесс, который будет блокироваться при вызове msgrcv.

Другим недостатком очередей сообщений System V по сравнению с сетевым интерфейсом является невозможность считывания сообщений из оперативной памяти (возможность, предоставляемая флагом MSG_PEEK для функций recv, recvfrom, recvmsg [24, с. 356]). Если бы такая возможность имелась, в предложенной только что схеме клиент-сервер (для обхода проблемы с select) можно было бы сделать работу более эффективной, указав флаг peek при вызове msgrcv дочерним процессом и записав 1 байт в канал при приходе сообщения, а родительский процесс тогда просто считывал бы сообщение из очереди.

6.10. Ограничения, накладываемые на очереди сообщений

Как отмечалось в разделе 3.8, на очереди сообщений часто накладываются системные oгрaничeния. В табл. 6.2 приведены значения этих oгрaничeний для двух конкретных реализаций. Первая колонка представляет собой традиционное имя System V для переменной ядра, хранящей это ограничение.

Таблица 6.2. Характерные значения ограничений для очередей сообщений

Имя	Описание	DUnix 4.0B	Solaris 2.6
msgmax	Максимальное количество байтов в сообщении	8192	2048
msgmnb	Максимальное количество байтов в очереди сообщений	16384	4096
msgmni	Максимальное количество очередей сообщений в системе	64	50
msgtlq	Максимальное количество сообщений в системе	40	40

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

Пример

В листинге 6.21 приведен текст программы, которая определяет четыре ограничения, показанные в табл. 6.2.

Листинг 6.21. Определение системных ограничений для очередей сообщений System V

//svmsg/limits.c
1  #include "unpipc.h"
2  #define MAX_DATA 64*1024
3  #define MAX_NMESG 4096
4  #define MAX_NIDS 4096
5  int max_mesg;

6  struct mymesg {
7   long type;
8   char data[MAX_DATA];
9  } mesg;

10 int
11 main(int argc, char **argv)
12 {
13  int i, j, msqid, qid[MAX_NIDS];
14  /* определение максимального размера сообщения */
15  msqid = Msgget(IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);
16  mesg.type = 1;
17  for (i = MAX_DATA; i > 0; i –= 128) {
18   if (msgsnd(msqid, &mesg, i, 0) == 0) {
19    printf("maximum amount of data per message = %d\n", i);
20    max_mesg = i;
21    break;
22   }
23   if (errno != EINVAL)
24    err_sys("msgsnd error for length %d", i);
25  }
26  if (i == 0)
27   err_quit("i == 0");
28  Msgct(lmsqid, IPC_RMID, NULL);
29  /* количество сообщений в очереди */
30  mesg.type = 1;
31  for (i = 8; i <= max_mesg; i *= 2) {
32   msqid = Msgget(IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);
33   for (j = 0; j < MAX_NMESG; j++) {
34    if (msgsnd(msqid, &mesg, i, IPC_NOWAIT) != 0) {
35     if (errno == EAGAIN)
36      break;
37     err_sys("msgsnd error, i = %d, j = %d", i, j);
38     break;
39    }
40   }
41   printf("%d %d-byte messages were placed onto queue,", j, i);
42   printf(" %d bytes total\n". i*j);
43   Msgctl(msqid, IPC_RMID, NULL);
44  }
45  /* максимальное количество идентификаторов */
46  mesg.type = 1;
47  for (i = 0; i <= MAX_NIDS; i++) {
48   if ((qid[i] = msgget(IPC_PRIVATE, SVMSG_MODE | IPC_CREAT)) == –1) {
49    printf("%d identifiers open at once\n", i);
50    break;
51   }
52  }
53  for (j = 0; j < i; j++)
54   Msgctl(qid[j], IPC_RMID, NULL);
55  exit(0);
56 }

Определение максимального размера сообщения

14-28 Для определения максимально возможного размера сообщения мы пытаемся послать сообщение, в котором будет 65 536 байт данных, и если эта попытка оказывается неудачной, уменьшаем этот объем до 65 408, и т.д., пока вызов msgsnd не окажется успешным.

Сколько сообщений различного размера может быть помещено в очередь?

29-44 Теперь мы начинаем с 8-байтовых сообщений и смотрим, сколько их поместится в очередь. После определения этого ограничения мы удаляем очередь (сбрасывая все эти сообщения) и повторяем процедуру с 16-байтовыми сообщениями. Мы повторяем это до тех пор, пока не будет достигнут максимальный размер сообщения из первого пункта. Ожидается, что небольшие сообщения будут превышать ограничение по количеству сообщений в очереди, а большие — ограничение по количеству байтов.

Сколько идентификаторов может быть открыто одновременно?

45-54 Обычно есть системное ограничение на количество одновременно открытых идентификаторов. Оно определяется непосредственно созданием очередей до тех пор, пока не произойдет ошибка при вызове msgget.

Запустим эту программу сначала в Solaris 2.6, а затем в Digital Unix 4.0B, и результаты подтвердят приведенные в табл. 6.2 величины:

solaris % limits
maximum amount of data per message = 2048
40 8-byte messages were placed on queue, 320 bytes total
40 16-byte messages were placed on queue, 640 bytes total
40 32-byte messages were placed on queue, 1280 bytes total
40 64-byte messages were placed on queue, 2560 bytes total
32 128-byte messages were placed on queue, 4096 bytes total
16 256-byte messages were placed on queue, 4096 bytes total
8 512-byte messages were placed on queue, 4096 bytes total
4 1024-byte messages were placed on queue, 4096 bytes total
2 2048-byte messages were placed on queue, 4096 bytes total
50 identifiers open at once

alpha % limits
maximum amount of data per message = 8192
40 8-byte messages were placed on queue, 320 bytes total
40 16-byte messages were placed on queue, 640 bytes total
40 32-byte messages were placed on queue, 1280 bytes total
40 64-byte messages were placed on queue, 2560 bytes total
40 128-byte messages were placed on queue, 5120 bytes total
40 256-byte messages were placed on queue, 10240 bytes total
32 512-byte messages were placed on queue, 16384 bytes total
16 1024-byte messages were placed on queue, 16384 bytes total
8 2048-byte messages were placed on queue, 16384 bytes total
4 4096-byte messages were placed on queue, 16384 bytes total
2 8192-byte messages were placed on queue, 16384 bytes total
63 identifiers at once

Причина, по которой в Digital Unix 4.0В получился результат 63 идентификатора, а не 64, как в табл. 6.2, заключается в том, что один идентификатор всегда используется системным демоном.

6.11.Резюме

Очереди сообщений System V аналогичны очередям сообщений Posix. При создании новых приложений следует рассмотреть возможность использования очередей сообщений Posix, но большое количество существующих программ использует очереди сообщений System V. Тем не менее переписать их для использования очередей Posix вместо очередей System V не должно быть слишком сложно. Главный недостаток очередей Posix заключается в невозможности считывания сообщений с произвольным приоритетом. Ни один из типов очередей не использует обычные дескрипторы, что делает сложным применение функций select и poll для очередей сообщений.

Упражнения

1. Почему на рис. 6.2 для сообщений, передаваемых серверу, используется тип 1?

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

3. Переделайте реализацию очередей сообщений Posix из раздела 5.8 для использования очередей сообщений System V вместо отображения в память. 

ЧАСТЬ 3