QNX/UNIX: Анатомия параллелизма

#include

#include

#include

#include

#include "/home/ZZZ/TESTS/MR/MessTest.h"

int main() {

 int fdRM; // Дескриптор соединения с менеджером ресурсов

 char BufferSend[MESSIZE_MAX], BufferReply[MESSIZE_MAX];

 setlocale(LC_CTYPE, "C-TRADITIONAL");

 if (fdRM = open(strcat(strcpy(BufferSend, NET_REG),

  "/dev/MESSTEST/RM"), O_RDWR)) == -1)) {

  printf("Клиент не нашел имени менеджера!\n");

  fflush(stdout);

  return(-1);

 }

 /* Заполнение заголовка - первых 4-х байт сообщения, содержащего

    инвентаризационную метку данного процесса (описаны в "IRL32.h") */

 ((int *)(BufferSend))[0] = 0x5002;

 /* Заполнение сообщения */

 strcpy(BufferSend + 4, "Так вот ты какой, Менеджер Ресурсов!");

 if (MsgSend(fdRM, BufferSend, 100, BufferReply, 100) == -1)

  printf("Клиенту не удалось передать сообщение\n");

 else

  printf("Клиент передал сообщение и получил <%s>\n", BufferReply);

 fflush(stdout);

 close(fdRM);

 return(0);

}

Код процесса-сервера (менеджера ресурсов)

Для запуска сервера на удаленном узле выполните с терминала команду:

# on -f /net/Bed-Test /net/904-3/home/ZZZ/BIN/TestMGR

где Bed-Test— имя удаленного узла, 904-3— имя локального узла, /home/ZZZ/BIN/TestMGR— путь к исполняемому файлу.

Вначале сервер выполняет действия по своей инициализации, специфические для данного процесса. Если они завершились успешно, т.е. сервер готов обслуживать клиентов, он инициализирует себя как администратор устройства (функции dispatch_create(), memset(&resmgr_attr, ...), iofunc_func_init(), resmgr_attach(), message_attach(), dispatch_context_alloc()), при этом на том узле, где запущен менеджер, появляется файл /dev/MESSTEST/RM. После этого, если все прошло успешно, сервер выходит на бесконечную петлю приема сообщений.

Прием сообщений осуществляется функцией dispatch_block(), блокирующей процесс-сервер на ожидании сообщений. При получении сообщения оно передается функции dispatch_handler(), которая производит разборку сообщения. Если это сообщение относится к известным разборщику, оно направляется к соответствующей функции обработки, принимаемой по умолчанию.

Так, в частности, обрабатываются сообщения на открытие ресурса (пересылаемое клиентом при вызове им функции open()), на отсоединение и закрытие ресурса (отсылаются клиентом при вызове им функции close()), на чтение или запись (если клиент вызовет функции read()или write()) и ряд других. Кроме того, разборщику известны сообщения, заголовок которых содержит «инвентаризационную метку», попадающую в диапазон, указанный при вызове функции присоединения приватных сообщений message_attach(). В этом случае сообщение передается для дальнейшей обработки функции-обработчику приватных сообщений (в нашем примере это функция PrivatHandler()).

При рассмотрении функции обработки приватных сообщений PrivatHandler()следует обратить внимание, что, хотя в этой функции и предусмотрено освобождение клиента с Reply-блокировки, она возвращает не _RESMGR_NOREPLY, как можно было бы ожидать, а значение 0, что указывает библиотеке менеджера ресурсов на то, что отвечать Reply-сообщением клиенту уже нет необходимости. Это объясняется тем, что обработчик приватных сообщений сам выполняет Reply-сообщение, и это заложено в нем изначально. В этом состоит важное отличие этого обработчика от всех прочих (взгляните на код обработчика prior_read()в разделе «Менеджеры ресурсов» главы 5).

Еще одна тонкость: при работе с приватными сообщениями в процессе-менеджере необходимо использовать функции диспетчеризации dispatch_*()( dispatch_block(), dispatch_handler()и т.д.), а не функции менеджера ресурсов resmgr_*()( resmgr_block(), resmgr_handler()и т.д.).

#include

#include

#include

#include

#include

#include

#include

#include

#include