Первый шаг в написании менеджера ресурса состоял в том, что я просто скопировал достаточно объёмный исходный текст примера много потокового менеджера ресурса из HELP подсистемы QNX, откомпилировал, и … это заработало (ещё один и заслуженный реверанс в сторону качества поставляемой с QNX технической документации). Всё последующее 2-х недельное “выкручивание рук” этому, пока ещё ничего осмысленного не делающего, МР было делом рутинной техники.

Подобная “технология” подтверждает ещё одно предположение: приложение МР (посредством которого в QNX можно описать всё или почти всё) в основной части кода является единообразным шаблоном, который нужно не столько писать, сколько незначительно подправить под специфику своего “ресурса” (около 75% строк кода файла Phone.cpp составляет “шаблонный” код менеджера ресурса).

Первым побуждением при написании проекта было создание единого проекта-приложения (в терминологии PhAB), первая часть которого (инициализация) создавала бы МР, регистрирующий уникальное имя (в проекте /proc/talk), а вторая – реализовывала бы пользовательский интерфейс к аналогичным МР на других хостах. Достаточно продолжительные эксперименты показали, что этот путь – не плодотворный. Это – не работает в принципе, и это особенность МР, которая не отражена нигде в документации, и на которой следует остановиться подробнее.

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

Отсюда следует, что рассматриваемый проект распадается на два процесса: процесс, регистрирующий имя /proc/talk, и клиентский процесс, обеспечивающий пользовательские обращения к этому имени. Как оказалось, этот подход оказался плодотворнее и из других соображений.

Полученный в результате проект демонстрирует, помимо использования техники МР (но, собственно, благодаря ей и архитектуре QNX), две очень интересных особенности:

Комментарии к коду.

На рис.3 показан тот “ресурс”, которым мы управляем посредством интерфейса менеджера ресурса. Здесь же проставлены имена widget-ов, необходимые для понимания исходного кода.

Рис.4

Аналогично, рис.4 показывает изображение и именования элементов клиентского приложения, которое позволяет выбирать сетевые хосты и порождать новые соединения (сеансы).

• Запускаем на различных хостах приложения МР (исполнимый файл rmta). Для целей тестирования или отладки МР может быть запущен на единственном локальном хосте, при этом оба конца “канала” будут привязаны к единому компьютеру. Если на компьютере уже выполняется rmta, то вторая копия не может быть запущена (функция OnStartRM() в файле Phone.cpp).

• В виде, показанном на скринщоте, РМ при запуске выводит окно (на рис.2 – окно в верхнем левом углу), на котором выведено сообщение о том, что “При закрытии этого окна ресурс-менеджер останавливается”. Это сделано в иллюстрационных и отладочных целях. В противном случае останавливать (перегружать) МР можно только командой “kill” по pid процесса. Более естественный старт – “глухо - немой”, в режиме демона. Для этого нужно в файле Phone.cpp закомментировать строку:

n = read( h = hdf, buf, sizeof( buf ) );

Это связано с тем, что после возврата из функций read() и write() значение файлового дескриптора портится (обнуляется). Этот эффект - недоработки МР и манипуляции в нём с флагами. Чтобы не возиться с локализацией этой ошибки, вместо этого, файловый дескриптор просто присваивается промежуточной переменной перед операцией. Того же результата можно было добиться С++ трюком:

n = read( ( hdf ), buf, sizeof( buf ) );

2. При закрытии пользователем окна phone (завершении сеанса), реакция на закрытие заблокирована, и МР при очередном read() возвратит условную строку конца файла (строка sEof файла Common.h). По получению этой строки только объект Line закрывает окно, выполняя close() над файловым дескриптором (хотя бы только потому, что окна нужно уничтожать в паре – те которые составляют сеанс). Корректнее было бы реализовать признак EOF операции read() согласно POSIX – возвратом 0. Но в данном проекте это не принципиально.

[1] – “Writing Resource Manager” в HELP подсистеме операционной системы QNX RTP 6.1.

Тексты проекта.

В качестве приложения прилагается архив проекта , содержащий полные проекты PhAB. Задачи rmta и clitalk могут быть запущены из этого архива, или пересобрагы с помощью PhAB. Проекты испытывались в QNX RTP 6.1.  Ниже приводится только краткое перечисление исходных файлов проектов.