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

 // инициализация атрибутов менеджера

 memset(&resmgr_attr, 0, sizeof resmgr_attr);

 resmgr_attr.nparts_max = 1;

 resmgr_attr.msg_max_size = 2048;

 // инициализация таблиц функций обработчиков

 static resmgr_connect_funcs_t connect_funcs;

 static resmgr_io_funcs_t io_funcs;

 iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs,

  _RESMGR_IO_NFUNCS, &io_funcs);

 // здесь нами дописан всего один обработчик - операции read,

 // все остальное делается менеджером по умолчанию!

 io_funcs.read = prior_read;

 // инициализация атрибутной структуры, используемой

 // устройством.

 static iofunc_attr_t attr;

 iofunc_attr_init(&attr, S_IFNAM | 0666, 0, 0);

 // здесь создается путевое имя для менеджера

 id = resmgr_attach(dpp, &resmgr_attr, "/dev/prior",

  _FTYPE_ANY, 0, &connect_funcs, &io_funcs, &attr);

 if (id == -1)

  perror("attach name"), exit(EXIT_FAILURE);

 ctp = dispatch_context_alloc(dpp);

 // старт менеджера как бесконечный цикл ожидания

 // поступающих сообщений для диспетчеризации:

 while (true) {

  if ((ctp = dispatch_block(ctp)) == NULL)

   perror("block error"), exit(EXIT_FAILURE);

  dispatch_handler(ctp);

 }

}

Здесь использован простейший однопоточный шаблон написания менеджера. Менеджер отрабатывает только одну команду read(т.e. отрабатывает нестандартно; в целевом коде все остальные команды, например open, он отрабатывает по умолчанию). По команде readменеджер: а) возвращает в виде текстовой строки, завершающейся переводом строки, текущий приоритет (помните, что в QNX приоритеты «плавают»?), на котором он обрабатывает запрос, и б) делает это через один запрос, в оставшиеся разы создавая на всякий случай (почему «на всякий», сейчас станет понятно) ситуацию EOF (конца файла). Выполним несколько команд:

# prior &

# ls -l /dev/pr*

nrw-rw-rw- 1 root root 0 Dec 18 17:13 /dev/prior

Все соответствует нашим ожиданиям: менеджер ресурса запущен, он зарегистрировал в пространстве имен свое имя /dev/prior, по которому мы можем к нему обращаться. Теперь выполним обращения к нашему... «устройству». Для этого мы сознательно не станем пользоваться каким-либо специальным клиентом, запрашивающим наш созданный сервис, а воспользуемся самыми заурядными командами UNIX, которые ничего не подозревают о существовании нового сервиса:

# cat /dev/prior

10

# nice -n-5 cat /dev/prior

15

# nice -n-19 cat /dev/prior

29

Вот здесь и проявляется исключительная мощь техники написания менеджера ресурса: созданная минимальными средствами серверная служба «камуфлирует» специфичный QNX-механизм передачи сообщений микроядра под стандартные POSIX-запросы к файловой системе ( open, readи т.д.), и стандартные команды UNIX «не видят» отличий новой серверной службы от стандартных файлов (устройств) UNIX. Вот для достижения такой полной совместимости с «привычками» команд UNIX и созданы «на всякий случай» те особенности формата, возвращаемого запросами read, о которых упоминалось выше.

Теперь разработка, например драйвера некоторого специфичного устройства, перемещается из области шаманства «системного программиста» в область деятельности проблемного программиста, да и выполняется привычными высокоуровневыми инструментальными средствами, например С++.