Роб Кёртен - Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

}

В QNX/Neutrino он заменился бы на следующий:

rcvid = MsgReceive(chid, &msg, sizeof(msg), NULL);

if (rcvid == 0) { // 0 значит, что это импульс

switch (msg.pulse.code) {

case MyCodeTimer:

// Сработал наш таймер, сделать что-нибудь

break;

case MyCodeISR:

// Сработал наш ISR, сделать что-нибудь

break;

default:

// Неизвестный код импульса

break;

}

} else {

// rcvid - не нуль, значит, это обычное

// клиентское сообщение. Сделать что-нибудь.

}

Отметим, что это пример для случая, когда вы обрабатываете сообщения самостоятельно. Но поскольку мы рекомендуем использовать библиотеку администратора ресурсов, на самом деле ваша программа выглядела бы примерно так:

int main(int argc, char **argv) {

...

// Выполнить обычные инициализации

pulse_attach(dpp, 0, MyCodeTimer, my_timer_pulse_handler,

NULL);

pulse_attach(dpp, 0, MyCodeISR, my_isr_pulse_handler,

NULL);

...

}

На этот раз мы предписываем библиотеке администратора ресурсов ввести две проверки из предыдущего примера в основной цикл приема сообщений и вызывать две наши функции обработки ( my_timer_pulse_handler() и my_isr_pulse_handler() ) всякий раз, когда обнаруживаются нужные коды. Гораздо проще.

Если вы анализируете содержимое прокси (фактически игнорируя, что это прокси, и обрабатывая их как сообщения), то вы автоматически имеете дело с тем, что в QNX4 на прокси ответить нельзя. В QNX/Neutrino ответить на импульс тоже нельзя. Это означает, что у вас уже есть код, который либо анализирует идентификатор, возвращаемый функцией приема, и определяет, что это прокси, и отвечать не надо, либо смотрит на содержимое сообщения и по нему определяет, надо отвечать на это сообщение или нет.

К сожалению в QNX/Neutrino произвольные данные в импульс не запихнешь. Импульс имеет четко определенную структуру, и обойти это нельзя. Умным решением здесь было бы «имитировать» сообщение от прокси при помощи импульса и таблицы. Таблица содержала бы сообщения, которые раньше передавались посредством прокси. Получив импульс, вы использовали бы поле value в качестве индекса к этой таблице, выбрали бы из таблицы соответствующее сообщение и «притворились», что получено именно оно.

Обработчики прерываний в QNX4 могли либо возвратить идентификатор прокси (указывая этим, что надо переключить прокси и таким образом уведомить ее владельца о прерывании), либо возвратить нуль (что означало бы, что в дальнейшем ничего делать не требуется). В QNX/Neutrino механизм почти идентичен — за исключением того, что вместо возвращения идентификатора прокси вы возвращаете указатель на struct sigevent . Генерируемое событие может быть либо импульсом (ближайший аналог прокси), либо сигналом, либо созданием потока — как выберете, так и будет.

Также в QNX4 вы обязаны были иметь обработчик прерывания — даже в том случае, если он должен был только возвратить идентификатор прокси. В QNX/Neutrino вы можете привязать struct sigevent к вектору прерывания, используя InterruptAttachEvent() , и это событие будет генерироваться при каждой активизации данного вектора.

Перенос приложений из QNX4 в QNX/Neutrino или поддержка программы, функционирующей в обеих операционных системах, — это возможно, если придерживаться следующих правил:

• абстрагировать, абстрагировать и еще раз абстрагировать;

• развязывать, развязывать и еще раз развязывать.

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

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

Перенос сервера из QNX4 в QNX/Neutrino является более трудной задачей вследствие того, что QNX4-серверы были сделаны «вручную» и никогда не следовали четкой структуре подобно тому, как это принято в библиотеке администраторов ресурсов в QNX/Neutrino. Впрочем, в общем случае, если вы переносите что-то сильно аппаратно-зависимое (например, аудиодрайвер или блок-ориентированный дисковый драйвер), основная часть портируемого кода никак не связна с операционной системой, и ой как связана с собственно аппаратурой. Подход, который я обычно использовал для таких случаев, состоит в том, чтобы запрограммировать каркас «драйвера» и обеспечить набор четко определенных аппаратно-зависимых функций. Каркас будет отличаться для разных операционных систем, но аппаратно-зависимые функции получатся на удивление переносимыми.