Олег Цилюрик - QNX/UNIX: Анатомия параллелизма

setlocale(LC_CTYPE, "C-TRADITIONAL");

if ((CChanid = ChannelCreate(0)) == -1)

printf("Ребенок: странно, но не удалось создать"

" канал\n");

else

printf("Ребенок: канал CChanid = %i создан\n", CChanid);

Parpid = atoi(argv[1]);

printf("Ребенок сообщает: он жив благодаря папане"

" Parpid = %i\n", Parpid);

strcpy(BufName, "904-3");

if ((nid = netmgr_strtond(BufName, NULL)) == -1)

printf("Ребенок: узел \"%s\" не найден!\n", BufName);

else

printf("Ребенок: узел \"%s\" найден, его nid = %i\n", BufName, nid);

if ((coid =

ConnectAttach(nid, Parpid, atoi(argv[2]), _NTO_SIDE_CHANNEL, 0)) == -1) {

printf("Ребенок: странно, но дитя не смогло"

" установить канал связи с папаней\n");

return(-1);

}

printf("Ребенок: установил связь coid = %i с процессом"

" Parpid = %i на узле %i\n", coid, Parpid, nid);

// Вот здесь хорошее место, чтобы выполнить все действия,

// необходимые для развертывания данного процесса

itoa(CChanid, SendBuf, 10);

errno = 0;

if (MsgSend(coid, SendBuf, 100, SendBuf, 100) == -1)

printf("Ребенок: на MsgSend() к отцу получил"

" errno = %i\n", errno);

else

printf("Ребенок: на MsgSend() получен отклик"

" от родителя.\"%s\"\n", SendBuf);

rcvid = MsgReceive(CChanid, RecBuf, 100, NULL);

printf("Ребенок: от папани получено сообщение:"

" \"%s\"\n", RecBuf);

strcpy(RecBuf, "я здесь, папаня!");

if (MsgReply(rcvid, EOK, RecBuf, 100) == -1)

printf("Ребенок: почему-то не удалось ответить"

" папаше. Ау, где ты?\n");

printf("Ребенок: дитятко работу закончило\n");

ChannelDestroy(CChanid);

ConnectDetach(coid);

return(0);

}

Описанный выше способ построения функционирующей в сети системы процессов может быть реализован далеко не всегда. Зачастую клиенту не известна полная триада, позволяющая ему создать соединение с сервером. Вспомним, что в QNX 4, где для создания связи с другим процессом был необходим его идентификатор, существовала служба пространства имен, обеспечиваемая сервером службы nameloc. Сервер объявлял свое имя в пространстве имен с помощью функции qnx_name_attach(), а затем клиент, вызвав функцию qnx_name_locate(), получал от системы идентификатор сервера, по которому мог далее с ним общаться.

Разработчики QNX 6 настоятельно рекомендуют вместо использования службы имен выполнять сервер в виде менеджера ресурсов, причем настолько настоятельно, что до версии 6.3 аналог этой службы — менеджер службы глобальных имен gns— функционировал только локально. И надо признать, что мощь и изящество менеджера ресурсов являются очень убедительным подкреплением этих рекомендаций.

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

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

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

Самым очевидным и наиболее простым способом передачи сообщений к серверу является инкапсуляция сообщений в «сообщения управления устройством» — сообщения типа devctl(). Однако этот способ имеет существенный недостаток, заключающийся в том, что при взаимном обмене данными между сервером и клиентом, что является более общим и достаточно частым случаем, мы вынуждены передавать в обоих направлениях буферы одинаковой длины. Это объясняется тем, что функция devctl()имеет только один параметр для размеров обоих буферов. Поэтому в качестве универсального средства передачи сообщений применение этой функции выглядит непривлекательным.

К радости разработчиков, менеджер ресурсов предлагает функцию приватных сообщений io_msg()для сообщений типа _IO_MSG. Менеджер способен их обрабатывать после соответствующей «настройки», заключающейся в подключении диапазона сообщений, интерпретируемых как приватные (допустимые значения должны быть больше 0x1ff— диапазона, резервируемого за системой). При этом сервер в состоянии как сразу «отпустить» Reply-блокированного клиента, так и оставить его в этом состоянии до нужного момента.

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

В остальном все достаточно тривиально. Более подробно о том, как писать менеджеры ресурсов, можно прочитать в главе «Writing a Resource Manager» технической документации QNX, а также в книгах [1] и [4] (глава Олега Цилюрика «Драйверы»).

#define NET_OPER "/net/904-3"

#define NET_REG "/net/Bed-Test"

// Максимальная длина обычного стандартного сообщения.

#define MESSIZE_MAX 100

// Максимальная длина инвентаризационного имени процесса

#define PROC_NAME_MAX 100

struct IdLabel_t { // Структура, содержащая,

int id; // -.инвентаризационную метку процесса

char name[PROC_NAME_MAX]; // - инвентаризационное имя процесса

} IdLabel[] = {

/* диапазон выделенный Группе # 1: от 0x5000 до 0x50ff */

0x5001, "пробный менеджер ресурсов",

0x5002, "первый тестовый клиент для менеджера ресурсов",