‘истемнаЯ архитектура QNX4

        ‘истемнаЯ архитектура QNX4

---------------------------------------------------------------
     (‘) QNX Software Systems Ltd., 1996
     Ђвтор: QNX Software Systems Ltd.
     ђусское издание: SWD Software Ltd.
     WWW: http://www.swd.ru/qnx/support/literature/sysarch/
     E-mail: books.qnx@swd.ru
     Date: 04 Mar 2002
---------------------------------------------------------------

</pre>
<div align=right><table bgcolor=#aabbcc width=50%><tr><td>
‚первые на русском Языке книга о QNX.
ђоб Љертен "‚ведение в QNX/Neutrino 2". <a href=http://www.swd.ru/qnx/support/literature/5-94656-025-9.html>ЂннотациЯ</a>,
<a href=http://www.swd.ru/qnx/support/literature/request/>‡аказ печатной версии(400 р.)</a></td></tr></table></div>

<h1><a name="id1">‘истемнаЯ архитектура QNX4</a></h1>


<p>Љнига <cite>‘истемнаЯ архитектура</cite> сопровождает операционную
систему QNX и предназначена как длЯ разработчиков приложений, так и длЯ
конечных пользователей.
<p>‚ книге подробно рассматриваетсЯ структура и функции
QNX. ‚ ней описаны микроЯдро, системные менеджеры, а также уникальный
механизм свЯзи между процессами, основанный  на передаче сообщений.
Џрежде чем использовать QNX, рекомендуетсЯ сначала прочитать эту книгу.

<p>‡а информацией об установке и использовании QNX,
обратитесь к книге <cite>ђуководство пользователЯ</cite> Ћ‘ QNX
<p><em>‘истемнаЯ архитектура</em> содержит следующие главы:
<ul>
<li> <a href="#p1">ЉонцепциЯ QNX;</a></li>
<li> <a href="#p2">ЊикроЯдро;</a></li>
<li> <a href="#p3">Њенеджер процессов;</a></li>
<li> <a href="#p4">Џространство имен ввода/вывода;</a></li>
<li> <a href="#p5">Њенеджер файловой системы;</a></li>
<li> <a href="#p6">Њенеджер устройств;</a></li>
<li> <a href="#p7">Њенеджер сети;</a></li>
<li> <a href="#p8">ЋконнаЯ система Photon microGUI.</a></li>
</ul>


<!-- 1  -->
<br><br>
<a name="p1">&nbsp;</a>
<h2>ЉонцепциЯ QNX</h2>

<p>ќта глава охватывает следующие темы:
<ul><li><a href="#WHATISQNX">что такое QNX?;
</a></li><li><a href="#MICROKERNELARCHITECTURE">архитектура микроЯдра;
</a></li><li><a href="#IPC">свЯзь между процессами (IPC);
</a></li><li><a href="#QNXASANETWORK">QNX как сеть.
</a></li></ul>


<h3><a name="WHATISQNX">—то такое QNX?
</a></h3>
<p>ѓлавнаЯ обЯзанность операционной системы состоит в управлении
ресурсами компьютера. ‚се действиЯ в системе - диспетчеризациЯ
прикладных программ, запись файлов на диск, пересылка данных по сети и
т.п. - должны выполнЯтьсЯ совместно настолько слитно и прозрачно,
насколько это возможно.

<p>Ќекоторые области применениЯ предъЯвлЯют более жесткие требованиЯ
к управлению ресурсами и диспетчеризации программ, чем другие.
ЏриложениЯ реального времени, например, полагаютсЯ на способность
операционной системы обрабатывать многочисленные событиЯ в пределах
ограниченного интервала времени. —ем быстрее реагирует операционнаЯ
система, тем большее пространство длЯ маневра имеет приложение
реального времени в пределах жестких временных рамок.

<p>ЋперационнаЯ система QNX идеальна длЯ приложений реального
времени. Ћна обеспечивает все неотъемлемые составлЯющие системы
реального времени:  многозадачность, диспетчеризацию программ на
основе приоритетов и быстрое переключение контекста.

<p>QNX - удивительно гибкаЯ система. ђазработчики легко могут
настроить операционную систему таким образом, чтобы она отвечала
требованиЯм конкретных приложений. QNX позволЯет вам создать систему,
использующую только необходимые длЯ решениЯ вашей задачи ресурсы.
ЉонфигурациЯ системы может изменЯтьсЯ в широком диапазоне - от Ядра с
несколькими небольшими модулЯми до полноценной сетевой системы,
обслуживающей сотни пользователей.

<p>QNX достигает своего уникального уровнЯ производительности,
модульности и простоты благодарЯ двум фундаментальным принципам:

<ul><li> архитектура на основе микроЯдра;
</li><li> свЯзь между процессами на основе сообщений.
</li></ul>

<h3><a name="MICROKERNELARCHITECTURE">Ђрхитектура микроЯдра системы QNX</a></h3>
<p>QNX состоит из небольшого Ядра, координирующего работу
взаимодействующих процессов. Љак показано на рисунке, структура больше
напоминает не иерархию, а команду, в которой несколько игроков одного
уровнЯ взаимодействуют между собой и со своим "защитником" - Ядром.

<p><hr>
<p><img src="qnx4-modules.gif" alt="fig: i/modules.gif">
<hr>

<p><i>ЊикроЯдро системы QNX координирует работу системных менеджеров.</i>
<pre>

</pre>

<p><b><a name="id4">ЌастоЯщее Ядро</a></b>
<p><em>џдро</em> - это "сердце" любой операционной системы.
‚ некоторых операционных системах на него возлагаетсЯ так много
функций, что Ядро, по сути, заменЯет всю операционную систему!

<p>‚ QNX же ЊикроЯдро - это настоЯщее Ядро. ‚о-первых, как и следует
Ядру реального времени, Ядро QNX имеет очень маленький размер.
‚о-вторых, оно выполнЯет две важнейшие функции:

<ul><li><b>передача сообщений</b> - ЊикроЯдро  обеспечивает
маршрутизацию всех сообщений между всеми процессами в системе;
</li><li><b>диспетчеризациЯ</b> - планировщик - это часть
ЊикроЯдра, и он получает управление всЯкий раз, когда процесс изменЯет
свое состоЯние в результате получениЯ сообщениЯ или прерываниЯ.

</li></ul><p>‚ отличие от всех остальных процессов, Ядро никогда не получает
управлениЯ в результате диспетчеризации.  ‚ходЯщий в состав Ядра код
выполнЯетсЯ только в результате прЯмых вызовов из процесса или
аппаратного прерываниЯ.


<p><b><a name="id5">‘истемные процессы</a></b>
<p>‚се услуги операционной системы,  за  исключением  тех,  которые
выполнЯютсЯ  Ядром,  в QNX предоставлЯютсЯ через стандартные процессы.
’ипичнаЯ конфигурациЯ QNX имеет следующие системные процессы:

<ul><li> Њенеджер процессов (<tt>Proc</tt>);</li>
<li> Њенеджер файловой системы (<tt>Fsys</tt>);</li>
<li> Њенеджер устройств (<tt>Dev</tt>);</li>
<li> Њенеджер сети (<tt>Net</tt>).</li></ul>
<h3><a name="id6">‘истемные и пользовательские процессы</a></h3>
<p>‘истемные процессы практически ничем не отличаютсЯ от любых
написанных пользователем программ - они не имеют какого-либо скрытого
или особого интерфейса, недоступного пользовательским процессам.

<p>€менно за счет такой системной архитектуры QNX обладает
уникальной наращиваемостью. ’ак как большинство услуг операционной
системы предоставлЯютсЯ стандартными процессами QNX, то расширение
операционной системы требует всего лишь написаниЯ новой программы,
обеспечивающей новую услугу!

<p>”актически, граница между операционной системой и прикладной
программой может быть очень размыта. …динственный критерий, по которому
мы можем отличить прикладные процессы и системные сервисные процессы,
состоит в том, что процесс операционной системы управлЯет каким-либо
ресурсом в интересах прикладного процесса.

<p>Џредположим, что вы написали сервер базы данных. Љак же должен
быть классифицирован этот процесс?

<p>’очно так же, как сервер файловой системы принимает запросы (в QNX
реализованные через механизм сообщений) на открытие файлов и запись
или чтение данных, это будет делать и сервер базы данных. •отЯ запросы
к серверу базы данных могут быть и более сложными, сходство обоих
серверов заключаетсЯ в том, что оба они обеспечивают доступ к ресурсу
посредством запросов.  Ћба они ЯвлЯютсЯ независимыми процессами,
которые могут быть написаны пользователем и запускатьсЯ по мере
необходимости.

<p>‘ервер базы данных может рассматриватьсЯ как процесс в одном
случае и как приложение в другом. <em>ќто действительно не имеет
значениЯ!</em> ‚ажно то, что создание и выполнение таких процессов в QNX не
требует абсолютно никаких изменений в стандартных компонентах
операционной системы.


<h3><a name="id7">„райверы устройств</a></h3>
<p>„райверы устройств - это процессы, которые ЯвлЯютсЯ посредниками
между операционной системой и устройствами и избавлЯют операционную
систему от необходимости иметь дело с особенностЯми конкретных
устройств.

<p>’ак как драйверы запускаютсЯ как обычные процессы, добавление
нового драйвера в QNX не влиЯет на другие части операционной системы.
’аким образом, добавление нового драйвера в QNX не требует ничего,
кроме непосредственно запуска этого драйвера.

<p>Џосле запуска и завершениЯ процедуры инициализации, драйвер может
выбрать один из двух вариантов поведениЯ:

<ul><li>стать расширением определенного системного процесса;
</li><li>продолжать выполнение как независимый процесс.
</li></ul>

<h3><a name="IPC">‘вЯзь между процессами (IPC)</a></h3>
<p>‚ типичной длЯ многозадачной системы реального времени ситуации,
когда несколько процессов выполнЯютсЯ одновременно, операционнаЯ
система должна предоставить механизмы, позволЯющие им общатьсЯ друг с
другом.

<p>‘вЯзь между процессами (Interprocess communication, сокращенно
IPC) ЯвлЯетсЯ ключом к разработке приложений как совокупности
процессов, в которых каждый процесс выполнЯет отведенную ему часть
общей задачи.

<p>QNX предоставлЯет простой, но мощный набор возможностей IPC,
которые существенно облегчают разработку приложений, состоЯщих из
взаимодействующих процессов.


<p><b><a name="id9">Џередача сообщений</a></b>
<p>QNX была первой коммерческой операционной системой своего класса,
котораЯ использовала передачу сообщений в качестве основного способа
IPC. €менно последовательное воплощение метода передачи сообщениЯ в
масштабах всей операционной системы обусловливает мощность, простоту и
элегантность QNX.

<p>‘ообщениЯ в QNX - это последовательность байт, передаваемых от
одного процесса другому. ЋперационнаЯ система не пытаетсЯ
анализировать содержание сообщениЯ - передаваемые данные имеют смысл
только длЯ отправителЯ и получателЯ, и ни длЯ кого более.

<p>Џередача сообщениЯ позволЯет не только обмениватьсЯ данными, но и
ЯвлЯетсЯ способом синхронизации выполнениЯ нескольких процессов. Љогда
они посылают, получают или отвечают на сообщениЯ, процессы
претерпевают различные "изменениЯ состоЯниЯ", которые влиЯют на то,
когда и как долго они могут выполнЯтьсЯ.  ‡наЯ состоЯниЯ и приоритеты
процессов, Ядро организует их диспетчеризацию таким образом, чтобы
максимально эффективно использовать ресурсы центрального процессора
(–Џ).

<p>Џриложение реального времени и другие ответственные приложениЯ по
праву нуждаютсЯ в надежном механизме передачи сообщений, т.к. входЯщие
в состав этих приложений процессы тесно взаимосвЯзаны. ђеализованный в
QNX  механизм передачи сообщений способствует упорЯдочению и повышению
надежности программ.


<h3><a name="QNXASANETWORK">QNX как сеть</a></h3>
<p>‚ простейшем случае локальнаЯ сеть обеспечивает разделЯемый
доступ к файлам и периферийным устройствам длЯ нескольких соединенных
между собой компьютеров. QNX идет гораздо дальше этого простейшего
представлениЯ и объединЯет всю сеть в единый однородный набор
ресурсов.

<p>‹юбой процесс на любом компьютере в составе сети может
непосредственно использовать любой ресурс на любом другом компьютере.
‘ точки зрениЯ приложений, не существует никакой разницы между местным
или удаленным ресурсом, и использование удаленных ресурсов не требует
каких-либо специальных средств.  Ѓолее того, чтобы определить,
находитсЯ ли такой ресурс как файл или устройство на локальном
компьютере или на другом узле сети, в программу потребуетсЯ включить
специальный дополнительный код!

<p>Џользователи могут иметь доступ к файлам по всей сети,
использовать любое периферийное устройство, запускать программы на
любом компьютере сети (при условии, что они имеют надлежащие
полномочиЯ). ‘вЯзь между процессами осуществлЯетсЯ единообразно,
независимо от их местоположениЯ в сети.  ‚ основе такой прозрачной
поддержки сети в QNX лежит всеобъемлющаЯ концепциЯ IPC на основе
передачи сообщений.


<p><b><a name="id11">Њодель единого компьютера</a></b>
<p>QNX изначально проектировалсЯ как сетеваЯ операционнаЯ система. ‚
некоторых отношениЯх QNX сеть напоминает скорее большую ќ‚Њ, нежели
набор мини-компьютеров. ЏользователЯм известно, что в распорЯжении
любой из прикладных программ имеетсЯ большой набор ресурсов. Ќо в
отличие от большой ќ‚Њ, QNX обеспечивает быструю реакцию системы, т.к.
соответствующий объем вычислительных ресурсов может быть выделен на
каждом узле в соответствии с потребностЯми каждого пользователЯ.

<p>‚ условиЯх управлениЯ производством используютсЯ программируемые
контроллеры и другие устройства ввода/вывода, а также комплексы программ,
работающие в режиме реального времени, которым может потребоватьсЯ больше
ресурсов, чем другим менее ответственным приложениЯм, таким как текстовый
редактор. ‘еть QNX достаточно "отзывчива", чтобы поддерживать
<em>одновременно</em> оба этих типа приложений, QNX позволЯет сфокусировать
вычислительную мощность системы на производственном оборудовании (там, где
это необходимо), в то же времЯ, не жертвуЯ интерфейсом пользователЯ.


<p><b><a name="id12">ѓибкаЯ поддержка сети</a></b>
<p>QNX сеть может быть построена с использованием различного
оборудованиЯ и стандартных промышленных протоколов. ‚ силу своей
полной прозрачности длЯ прикладных программ и пользователей, новые
сетевые архитектуры могут быть внедрены в любое времЯ, не разрушаЯ
операционной системы.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>‘писок поддерживаемого QNX сетевого оборудованиЯ пополнЯетсЯ со
временем. „лЯ получениЯ подробной информации обратитесь к документации
на сетевое оборудование, которое вы используете.

</td>
</table>
<hr>

<p>Љаждому узлу QNX сети присваиваетсЯ уникальный номер, который
становитсЯ его идентификатором. ќтот номер также единственный видимый
признак того, функционирует QNX как сеть или как однопроцессорнаЯ
операционнаЯ система.

<p>’акаЯ степень прозрачности ЯвлЯетсЯ еще одним примером больших
возможностей архитектуры QNX, основанной на передаче сообщений. ‚о
многих операционных системах такие важные функции как поддержка сети,
IPC или даже передача сообщений выполнены в виде надстроек над
операционной системой, а не интегрированы непосредственно в ее
сердцевину. ђезультатом такого подхода ЯвлЯетсЯ неуклюжий и
неэффективный интерфейс с "двойным стандартом", когда свЯзь между
процессами - это одно дело, в то времЯ как проникновение в скрытый
интерфейс таинственного монолитного Ядра - совершенно другое дело!

<p>QNX, напротив, исходит из того, что эффективнаЯ свЯзь ЯвлЯетсЯ
ключом к эффективной работе. Џередача сообщений ЯвлЯетсЯ, таким образом,
краеугольным камнем архитектуры QNX, увеличивает эффективность <em>всех
без исключениЯ</em> транзакций между процессами в системе, независимо от
того, идет ли речь о передаче данных по внутренней шине персонального
компьютера или по коаксиальному кабелю на расстоЯние нескольких миль.

<p>’еперь давайте перейдем к более подробному рассмотрению структуры
QNX.


<!-- 1  -->


<!-- 2  -->


<h2><a name="p2">ЊикроЯдро</a></h2>

<p>ќта глава охватывает следующие темы:
<ul><li><a href="#INTRO">введение;
</a></li><li><a href="#KERNELIPC">свЯзь между процессами (IPC);
</a></li><li><a href="#IPCMESSAGES">IPC посредством сообщений;
</a></li><li><a href="#IPCPROXIES">IPC посредством прокси;
</a></li><li><a href="#IPCSIGNALS">IPC посредством сигналов;
</a></li><li><a href="#IPCNET">IPC в сети;
</a></li><li><a href="#IPCSEM">IPC посредством семафоров;
</a></li><li><a href="#SCHEDULING">диспетчеризациЯ процессов;
</a></li><li><a href="#REALTIMEPERFORMANCE">несколько слов о реальном времени.
</a> </li></ul>


<h3><a name="INTRO">‚ведение</a></h3>
<p>ЊикроЯдро QNX отвечает за выполнение следующих функций:
<ul><li>свЯзь между процессами - ЊикроЯдро управлЯет маршрутизацией
<em>сообщений</em>; оно также поддерживает две другие формы IPC -
<em>прокси</em> и <em>сигналы</em>;

</li><li>сетевой интерфейс низкого уровнЯ - ЊикроЯдро осуществлЯет
доставку всех сообщений, предназначенных длЯ процессов на других узлах
сети;

</li><li>диспетчеризациЯ процессов - входЯщий в состав џдра
<em>планировщик</em> решает, какому из запущенных процессов должно быть
передано управление;

</li><li>первичнаЯ обработка прерываний - все аппаратные прерываниЯ и
исключениЯ сначала проходЯт через ЊикроЯдро, а затем передаютсЯ
соответствующему драйверу или системному менеджеру.

</li></ul><hr>
<p><img src="qnx4-kernel.gif" alt="fig: i/kernel.gif">
<hr>

<p><i>‚нутри микроЯдра QNX.</i>
<pre>

</pre>

<h3><a name="KERNELIPC">‘вЯзь между процессами</a></h3>
<p>ЊикроЯдро QNX поддерживает три важнейшие формы свЯзи между
процессами: сообщениЯ, прокси и сигналы.

<ul><li><em>‘ообщениЯ</em> - это основополагающаЯ форма IPC в QNX.
Ћни обеспечивают синхронную свЯзь между взаимодействующими процессами,
когда процессу, посылающему сообщение, требуетсЯ получить
подтверждение того, что оно получено и, возможно, ответ.

</li><li><em>Џрокси</em> - это особый вид сообщениЯ. Ћни больше всего
подходЯт длЯ извещениЯ о наступлении какого-либо событиЯ, когда процессу,
посылающему сообщение, не требуетсЯ вступать в диалог с получателем.

</li><li><em>‘игналы</em> - это традиционнаЯ форма IPC. Ћни
используютсЯ длЯ асинхронной свЯзи между процессами.

</li></ul>

<h3><a name="IPCMESSAGES">IPC посредством сообщений</a></h3>
<p>‘ообщениЯ в QNX - это пакеты байт, которые синхронно
передаютсЯ от одного процесса к другому. QNX при этом не  анализирует
содержание сообщениЯ. Џередаваемые данные понЯтны только отправителю и
получателю и никому более.


<p><b><a name="id5">Џримитивы передачи сообщений</a></b>
<p>„лЯ непосредственной свЯзи друг с другом взаимодействующие
процессы используют следующие функции Языка программированиЯ ‘и:

<table border>
<tr><th>”ункциЯ Языка ‘и:
</th><th>Ќазначение:
</th></tr><tr><td><i>Send()</i></td><td>посылка сообщений
</td></tr><tr><td><i>Receive()</i></td><td>получение сообщений
</td></tr><tr><td><i>Reply()</i></td><td>ответ процессу, пославшему сообщение
</td></tr></table>
<p>ќти функции могут быть использованы как локально,  т.е. длЯ свЯзи
между процессами на одном компьютере,  так и в пределах сети, т.е. длЯ
свЯзи между процессами на разных узлах.

<p>‘ледует заметить, однако, что далеко не всегда возникает
необходимость использовать функции <i>Send()</i>, <i>Receive()</i> и
<i>Reply()</i> в Явном виде. Ѓиблиотека функций Языка ‘и в QNX построена
на основе использованиЯ сообщений - в результате, когда процесс использует
стандартные механизмы передачи данных (такие, как, например, программный
канал - pipe), он косвенным образом использует передачу сообщений.

<p><hr>
<p><img src="qnx4-messpass.gif" alt="fig: i/messpass.gif">
<hr>

<p><i>Џроцесс A посылает сообщение процессу B, который получает его,
обрабатывает и посылает ответ</i>

<pre>

</pre>

<p>Ќа рисунке изображена последовательность событий, имеющих место,
когда два процесса, процесс A и процесс B, используют функции
<i>Send()</i>, <i>Receive()</i> и <i>Reply()</i> длЯ свЯзи друг с другом:


<ol>
<li> Џроцесс A посылает сообщение процессу B, вызвав функцию <i>Send()</i>,
котораЯ передает соответствующий запрос Ядру. ‚ этот момент времени
процесс  A переходит в SEND-блокированное состоЯние и остаетсЯ в этом
состоЯнии до тех пор, пока процесс B не вызовет функцию <i>Receive()</i>
длЯ получениЯ сообщениЯ.

</li><li> Џроцесс B вызывает <i>Receive()</i> и получает сообщение от
процесса A. Џри этом состоЯние процесса A изменЯетсЯ на REPLY-блокирован.
Џроцесс B при вызове функции <i>Receive()</i> в данном случае не блокируетсЯ,
т.к. к этому моменту его уже ожидало сообщение от процесса A.

<p>‡аметьте, что если бы процесс B вызвал <i>Receive()</i> до того, как
ему было послано сообщение, то он бы попал в состоЯние RECEIVE-блокирован до
получениЯ сообщениЯ. ‚ этом случае процесс-отправитель сообщениЯ
немедленно после посылки сообщениЯ попал бы в состоЯние
REPLY-блокирован.
</li><li> Џроцесс B выполнЯет обработку полученного от процесса A
сообщениЯ и затем вызывает функцию <i>Reply()</i>. Ћтветное сообщение
передаетсЯ процессу A, который переходит в состоЯние готовности к
выполнению. ‚ызов <i>Reply()</i> не блокирует процесс B, который также готов
к выполнению. Љакой из этих процессов будет выполнЯтьсЯ, зависит от их
приоритетов.
</li></ol>


<p><b><a name="id6">‘инхронизациЯ процессов</a></b>
<p>Џередача сообщений не только позволЯет процессам обмениватьсЯ
данными, но и предоставлЯет механизм синхронизации выполнениЯ
нескольких взаимодействующих процессов.

<p>„авайте снова рассмотрим приведенный выше рисунок. Џосле того как
процесс A вызвал функцию <i>Send()</i>, он не может продолжать выполнение
до тех пор, пока не получит ответ на посланное сообщение. ќто
гарантирует, что выполнЯемаЯ процессом B по запросу процесса A
обработка данных будет завершена прежде, чем процесс A продолжит
выполнение. Ѓолее того, после вызова процессом B запроса на получение
данных <i>Receive()</i>, он не может продолжать выполнение до тех пор,
пока не получит следующее сообщение.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>Ѓолее подробно диспетчеризациЯ процессов в QNX рассматриваетсЯ в
разделе "<a href="#SCHEDULING">„испетчеризациЯ процессов</a>"
далее в этой главе.
</td>
</table>
<hr>

<p><b><a name="id7">Ѓлокированные состоЯниЯ</a></b>
<p>Љогда процессу не разрешаетсЯ продолжать выполнение, т.к. он
должен ожидать окончаниЯ определенной стадии протокола передачи
сообщениЯ, - процесс называетсЯ <em>блокированным</em>.

<p>‚озможные блокированные состоЯниЯ процессов приведены в следующей
таблице:

<table border>
<tr><th>…сли процесс выдал:
</th><th>’о процесс:
</th></tr><tr><td>‡апрос <i>Send()</i>, и отправленное им сообщение еще не получено процессом-получателем
</td><td>SEND-блокирован
</td></tr><tr><td>‡апрос <i>Send()</i>, и отправленное им сообщение получено процессом-получателем, но ответ еще не выдан
</td><td>REPLY-блокирован
</td></tr><tr><td>‡апрос <i>Receive()</i>, но еще не получил сообщение
</td><td>RECEIVE-блокирован
</td></tr></table>
<p><hr>
<p><img src="qnx4-states.gif" alt="fig: i/states.gif">
<hr>

<p><i>€зменение состоЯниЯ процессов в типичном случае передачи сообщениЯ.</i>
<pre>

</pre>


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>„лЯ получениЯ информации обо всех возможных состоЯниЯх процесса смотри
главу "<a href="#p3">Њенеджер процессов</a>".
</td>
</table>
<hr>

<p><b><a name="id8">€спользование <i>Send()</i>, <i>Receive()</i> и <i>Reply()</i></a></b>
<p>„авайте теперь более подробно рассмотрим вызовы функций <i>Send()</i>,
<i>Receive()</i> и <i>Reply()</i>. ‚оспользуемсЯ рассмотренным выше
примером передачи сообщениЯ от процесса A к процессу B.


<h3><a name="id9">”ункциЯ <i>Send()</i></a></h3>
<p>Џредположим, что процесс Ђ выдает запрос на передачу сообщениЯ
процессу ‚. ќто выполнЯетсЯ посредством вызова функции
<i>Send()</i>:


<pre>
Send( <i>pid</i>, <i>smsg</i>, <i>rmsg</i>, <i>smsg_len</i>, <i>rmsg_len</i> );
</pre>

<p>Џри вызове функции <i>Send()</i> используютсЯ следующие аргументы:
<dl>
<dt><i>pid</i></dt>
<dd>идентификатор процесса (<em>p</em>rocess <em>ID</em>), которому
предназначаетсЯ сообщение (т.е. процесса B); этот идентификатор
используетсЯ длЯ обращениЯ к процессу со стороны операционной
системы и других процессов;
</dd><dt><i>smsg</i></dt>
<dd>буфер сообщениЯ (т.е. сообщение, подлежащее посылке)
</dd><dt><i>rmsg</i></dt>
<dd>буфер ответа (будет содержать ответ от процесса B)
</dd><dt><i>smsg_len</i></dt>
<dd>длина посылаемого сообщениЯ в байтах
</dd><dt><i>rmsg_len</i></dt>
<dd>максимальнаЯ длина ответа, который может принЯть процесс A, в байтах
</dd></dl>
<p>Ћбратите внимание, что будет передано не более <i>smsg_len</i> байт и
не более чем <i>rmsg_len</i> байт будет получено в качестве ответа - это
гарантирует, что не произойдет случайного переполнениЯ буферов.


<h3><a name="id10">”ункциЯ <i>Receive()</i></a></h3>
<p>‚ызвав запрос <i>Receive()</i>, процесс B может получить сообщение,
направленное ему процессом A:


<pre>
<i>pid</i> = Receive( 0, <i>msg</i>, <i>msg_len</i> )
</pre>

<p>‚ызов функции <i>Receive()</i> содержит следующие аргументы:
<dl>
<dt><i>pid</i></dt>
<dd>идентификатор процесса, который послал сообщение (т.е. процесс A)
</dd><dt><tt>0</tt></dt>
<dd>(ноль) означает, что процесс B желает принЯть сообщение от любого
процесса
</dd><dt><i>msg</i></dt>
<dd>буфер, куда будет помещено принимаемое сообщение
</dd><dt><i>msg_len</i></dt>
<dd>максимальный размер данных, которые будут помещены в буфер приема, в байтах
</dd></dl>
<p>…сли значениЯ аргументов <i>smsg_len</i> в вызове функции <i>Send()</i>
и <i>msg_len</i> в вызове функции <i>Receive()</i> отличаютсЯ, друг от
друга, то наименьшее из них определЯет размер данных, которые будут
переданы.


<h3><a name="id11">”ункциЯ <i>Reply()</i></a></h3>
<p>Џосле успешного получениЯ сообщениЯ от процесса A, процесс B
должен ответить процессу A, вызвав функцию <i>Reply()</i>:


<pre>
Reply( <i>pid</i>, <i>reply</i>, <i>reply_len</i> );
</pre>

<p>‚ызов функции <i>Reply()</i> содержит следующие аргументы:
<dl compact>
<dt><i>pid</i></dt>
<dd>идентификатор процесса, которому предназначаетсЯ ответ (т.е. процесс A)
</dd><dt><i>reply</i></dt>
<dd>буфер, содержащий ответ
</dd><dt><i>reply_len</i></dt>
<dd>длина данных, передаваемых в качестве ответа, в байтах
</dd></dl>
<p>…сли значениЯ аргументов <i>reply_len</i> при вызове
функции <i>Reply()</i> и <i>rmsg_len</i> при вызове
функции <i>Send()</i> отличаютсЯ друг от друга, то
наименьшее из них определЯет размер передаваемых данных.


<p><b><a name="id12">Reply-управлЯемый обмен сообщениЯми</a></b>
<p>Џример обмена сообщениЯми, который мы только что рассмотрели,
иллюстрирует наиболее распространенный случай использованиЯ сообщений
- случай, когда длЯ процесса, выполнЯющего функции сервера, нормальным
ЯвлЯетсЯ состоЯние RECEIVE-блокирован в ожидании каких-либо запросов
клиента.  ќто называетсЯ <em>send-управлЯемый обмен сообщениЯми</em>:
процесс-клиент инициирует действие, посылаЯ сообщениЯ, ответ сервера на
сообщение завершает действие.

<p>‘уществует и другаЯ модель обмена сообщениЯми, не столь
распространеннаЯ, как рассмотреннаЯ выше, хотЯ в некоторых ситуациЯх
она даже более предпочтительна: <em>reply-управлЯемый обмен</em>
сообщениЯми, при котором действие инициируетсЯ вызовом функции
<i>Reply()</i>. ‚ этом случае процесс-"работник" посылает серверу
сообщение, говорЯщее о том, что он готов к работе. ‘ервер не отвечает
сразу, а "запоминает", что работник готов выполнить его задание.
‚ последствии сервер может инициировать действие, ответив ожидающему
задание работнику. Џроцесс-работник выполнит задание и завершит
действие, послав серверу сообщение, содержащее результаты своей работы.


<p><b><a name="id13">„ополнительные сведениЯ</a></b>
<p>Џри разработке программ, использующих передачу сообщений,
необходимо иметь в виду следующее:
<ul><li>сообщение сохранЯетсЯ в теле посылающего процесса до тех пор,
пока принимающий процесс не будет готов получить его. ‘ообщение <em>не</em>
копируетсЯ в ЊикроЯдро. ќто безопасно, т.к. посылающий процесс
SEND-блокирован и не может неумышленно изменить содержимое сообщениЯ

</li><li>при вызове функции <i>Reply()</i> данные копируютсЯ
из отвечающего процесса в REPLY-блокированный процесс как одна неразрывнаЯ
операциЯ. ‚ызов функции <i>Reply()</i> не блокирует
процесс - REPLY-блокированный процесс перестает быть блокированным после
того, как в него скопированы данные;

</li><li>при посылке сообщениЯ процессу не требуетсЯ знать состоЯние
того процесса, которому это сообщение адресовано. …сли получатель не
готов к приему сообщениЯ в момент его отправки, то посылающий сообщение
процесс просто становитсЯ SEND-блокирован;

</li><li>если это необходимо, то процесс может посылать сообщение
нулевой длины, ответ нулевой длины, либо и то и другое;

</li><li>с точки зрениЯ разработчика, использование <i>Send()</i> длЯ
передачи процессу-серверу запроса на получение какой-либо услуги
равнозначно вызову библиотечной подпрограммы, предоставлЯющей ту же
самую услугу. ‚ обоих случаЯх ваша программа сначала подготавливает
определенные данные, а затем вызывает либо функцию <i>Send()</i>, либо
библиотечную подпрограмму, после чего ожидает, когда они закончат
выполнение. ‚ обоих случаЯх код, реализующий запрашиваемую услугу,
выполнЯетсЯ между двумЯ четко определенными точками - <i>Receive()</i> и
<i>Reply()</i> длЯ процесса-сервера, входом в подпрограмму и командой
<tt>return</tt> длЯ вызова библиотечной подпрограммы. Љогда вызываемаЯ
сервиснаЯ программа завершена, ваша программа "знает", куда помещены
результаты, и может приступить к проверке возвращенного кода ошибки,
обработке результатов и так далее.

<p>ЌесмотрЯ на такую кажущуюсЯ простоту, вызов функции <i>Send()</i>
делает гораздо больше, чем простой вызов библиотечной подпрограммы.
”ункциЯ <i>Send()</i> может прозрачно длЯ вызывающей программы передать
запрос на другой узел сети, где и будет в действительности выполнЯтьсЯ
обслуживающий запрос код. Џри этом также может быть задействована
параллельнаЯ обработка данных без издержек на создание нового
процесса. Џроцесс-сервер может сразу, как только станет возможным,
вызвать функцию <i>Reply()</i>, позволЯЯ тем самым запрашивавшему процессу
возобновить выполнение и, в то же времЯ, продолжить выполнение самому.

</li><li>возможна ситуациЯ, когда сообщениЯ от многих процессов
одновременно ожидают своей обработки одним и тем же принимающим
процессом. Љак правило, принимающий процесс получает сообщение в том
же порЯдке, в каком они были посланы другими процессами; однако
принимающий процесс может установить очередность получениЯ сообщений
на основе приоритетов посылающих процессов.

</li></ul><p><hr>
<p><img src="qnx4-blocproc.gif" alt="fig: i/blocproc.gif">
<hr>

<p><i>‘ервер получил сообщение от клиента A и клиента B (но еще не
ответил им). ‘ообщениЯ от клиентов C, D, E еще не получены.</i>

<pre>

</pre>

<p><b><a name="ADVANCEDFAC">„ополнительные возможности</a></b>
<p>QNX также предоставлЯет следующие дополнительные возможности по
передаче сообщений:

<ul><li>условный прием сообщений;
</li><li>чтение или запись части сообщений;
</li><li>составные сообщениЯ (сообщениЯ, состоЯщие из нескольких частей).
</li></ul>
<h3><a name="id15">“словный прием сообщений</a></h3>
<p>Ћбычно, когда процесс хочет принЯть сообщение, он вызывает
функцию <i>Receive()</i> длЯ ожиданиЯ прихода сообщениЯ. ќто обычный
способ получениЯ сообщений, который пригоден в большинстве случаев.

<p>Ћднако возможна ситуациЯ, когда процессу необходимо определить,
имеютсЯ ли ожидающие приема сообщениЯ, не попадаЯ при этом в состоЯние
RECEIVE-блокирован в случае их отсутствиЯ. Ќапример, процессу
требуетсЯ опрашивать работающее с высокой скоростью устройство,
которое не способно генерировать прерывание, и в то же времЯ он должен
отвечать на сообщениЯ от других процессов. ‚ этом случае процесс может
использовать функцию <i>Creceive()</i>, котораЯ либо прочитает ожидающее
приема сообщение, либо немедленно вернет управление процессу в случае
отсутствиЯ ожидающих приема сообщений.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>‘ледует по возможности избегать использованиЯ функции
<i>Creceive()</i>, т.к. она позволЯет процессу непрерывно выполнЯтьсЯ
с неизменЯющимсЯ уровнем приоритета.
</td>
</table>
<hr>


<h3><a name="id16">—тение или запись части сообщениЯ</a></h3>
<p>€ногда желательно читать или записывать сообщениЯ по частЯм с
тем, чтобы использовать уже выделенный длЯ сообщениЯ буфер вместо
выделениЯ отдельного рабочего буфера.

<p>Ќапример, менеджер ввода/вывода может принимать данные в виде
сообщений, которые состоЯт из заголовка фиксированной длины и
следующих за ним данных переменной длины. ‚ заголовке указываетсЯ
размер данных (от 0 до 64 Љбайт). ‚ этом случае менеджер
ввода/вывода может сначала принЯть только заголовок сообщениЯ, а затем
использовать функцию <i>Readmsg()</i> длЯ чтениЯ данных переменной длины
непосредственно в соответствующий буфер вывода. …сли размер данных
превышает размер буфера, то менеджер может неоднократно вызывать
функцию <i>Readmsg()</i> по мере освобождениЯ буфера вывода. Ђналогичным
образом, функциЯ <i>Writemsg()</i> может быть использована длЯ поэтапного
копированиЯ данных в выделенный длЯ ответного сообщениЯ буфер
непосредственно в теле процесса, пославшего сообщение, уменьшаЯ, таким
образом, потребность менеджера ввода/вывода в выделении внутренних
буферов.


<h3><a name="id17">‘оставные сообщениЯ</a></h3>
<p>„о сих пор мы рассматривали сообщениЯ как непрерывную
последовательность байт. Ћднако сообщениЯ часто состоЯт из двух или
более отдельных частей. Ќапример, сообщение может иметь заголовок
фиксированной длины, за которым следуют данные переменной длины. „лЯ
того чтобы избежать копированиЯ частей такого сообщениЯ во временные
промежуточные буферы при передаче или приеме, может быть использовано
составное сообщение, состоЯщее из двух или более отдельных буферов
сообщений. €менно благодарЯ этой возможности менеджеры ввода/вывода
QNX, такие как <tt>Dev</tt> и <tt>Fsys</tt>, достигают своей высокой
производительности.

<p>‘ледующие функции позволЯют обрабатывать составные сообщениЯ:

<ul PLAIN="PLAIN"><li><i>Creceivemx()</i>

</li><li><i>Readmsgmx();</i>
</li><li><i>Receivemx();</i>
</li><li><i>Replymx();</i>
</li><li><i>Sendmx();</i>
</li><li><i>Writemsgmx().</i>

</li></ul><p><hr>
<p><img src="qnx4-multimsg.gif" alt="fig: i/multimsg.gif">
<hr>

<p><i>‘оставные сообщениЯ могут быть описаны с помощьюqqqЏ0 специальной mx
структуры. ЊикроЯдро объединЯет части такого сообщениЯ в единый
непрерывный поток данных.</i>
<pre>

</pre>

<p><b><a name="id18">‡арезервированные коды сообщений</a></b>
<p>QNX начинает все сообщениЯ с 16-ти битного слова, называемого
<em>кодом сообщениЯ</em>. ‡аметим, однако, что это не ЯвлЯетсЯ
обЯзательным длЯ вас требованием при написании собственных программ.
QNX использует коды сообщений в следующих диапазонах:

<table border>
<tr><th>‡арезервированный диапазон:
</th><th>Ћписание:
</th></tr><tr><td><tt>0x0000</tt> - <tt>0x00FF</tt></td>
<td>‘ообщениЯ Њенеджера процессов
</td></tr><tr><td><tt>0x0100</tt> - <tt>0x01FF</tt></td>
<td>‘ообщениЯ ввода/вывода (общие длЯ всех серверов ввода/вывода)
</td></tr><tr><td><tt>0x0200</tt> - <tt>0x02FF</tt></td>
<td>‘ообщениЯ Њенеджера файловой системы
</td></tr><tr><td><tt>0x0300</tt> - <tt>0x03FF</tt></td>
<td>‘ообщениЯ Њенеджера устройств
</td></tr><tr><td><tt>0x0400</tt> - <tt>0x04FF</tt></td>
<td>‘ообщениЯ Њенеджера сети
</td></tr><tr><td><tt>0x0500</tt> - <tt>0x0FFF</tt></td>
<td>‡арезервированы длЯ будущих системных процессов QNX
</td></tr></table>


<h3><a name="IPCPROXIES">IPC посредством прокси</a></h3>
<p><em>Џрокси</em> - это форма неблокирующего сообщениЯ, особенно
подходЯщего длЯ извещениЯ о наступлении событиЯ, когда посылающий процесс
не нуждаетсЯ в диалоге с получателем. …динственнаЯ функциЯ прокси состоит
в посылке фиксированного сообщениЯ определенному процессу, который
ЯвлЯетсЯ владельцем прокси.  Џодобно сообщениЯм, прокси могут быть
использованы в пределах всей сети.

<p>€спользуЯ прокси, процесс или обработчик прерываниЯ может послать
сообщение другому процессу, не блокируЯсь и не ожидаЯ ответа.

<p>‚от некоторые примеры использованиЯ прокси:

<ul><li>процесс желает известить другой процесс о наступлении
какого-либо событиЯ, но при этом не может позволить себе посылку
сообщениЯ (в этом случае он оставалсЯ бы блокированным до тех
пор, пока получатель не вызовет <i>Receive()</i> и <i>Reply()</i>);

</li><li>процесс хочет послать данные другому процессу, но при этом
ему не требуетсЯ ни ответа, ни какого-либо другого подтверждениЯ того,
что адресат (получатель) получил сообщение;

</li><li>обработчик прерываниЯ хочет известить процесс о поступлении
новых данных.
</li></ul>

<p>„лЯ созданиЯ прокси используетсЯ функциЯ Языка ‘и
<i>qnx_proxy_attach()</i>. ‹юбой другой процесс или обработчик прерываниЯ,
которому известен идентификатор прокси, может воспользоватьсЯ функцией
Языка ‘и <i>Trigger()</i> длЯ того, чтобы заставить прокси передать
заранее заданное сообщение. ‡апрос <i>Trigger()</i> обрабатываетсЯ
ЊикроЯдром.

<p>Џрокси может быть "запущено" неоднократно - каждый раз при этом
оно посылает сообщение. Џрокси может накапливать очередь длиной до
65535 сообщений.

<p><hr>
<p><img src="qnx4-prxytrig.gif" alt="fig: i/prxytrig.gif">
<hr>

<p><i>Џроцесс-клиент запускает прокси 3 раза,  в результате чего сервер
получает 3 "консервированных" сообщениЯ от прокси.</i>
<pre>

</pre>


<h3><a name="IPCSIGNALS">IPC посредством сигналов</a></h3>
<p>‘игналы ЯвлЯютсЯ традиционным способом асинхронной свЯзи, котораЯ
используетсЯ в течение многих лет в различных операционных системах.

<p>QNX поддерживает большой набор сигналов, соответствующих стандарту
POSIX, кроме того, сигналы, исторически присущие некоторым UNIX-системам,
и рЯд сигналов, уникальных длЯ QNX.


<p><b><a name="id21">Љак породить сигнал</a></b>
<p>‘читаетсЯ, что сигнал доставлен процессу тогда, когда выполнЯетсЯ
определенное в процессе длЯ данного сигнала действие. Џроцесс может
посылать сигнал самому себе.

<table border>
<tr><th>…сли вы хотите:
</th><th>€спользуйте:
</th></tr><tr><td>Џородить сигнал из командной строки
</td><td>“тилиты: <tt>kill</tt> и <tt>slay</tt></td></tr>
<tr><td>Џородить сигнал внутри процесса
</td><td>”ункции ‘и: <i>kill()</i> и <i>raise()</i></td></tr></table>

<p><b><a name="id22">Џолучение сигналов</a></b>
<p>Џроцесс может принЯть сигнал одним из трех способов, в
зависимости от того, как в процессе определена обработка сигналов:

<ul><li>если процесс не определил никаких специальных мер по обработке
сигнала, то выполнЯетсЯ предусмотренное длЯ сигнала действие по
умолчанию - обычно таким действием по умолчанию ЯвлЯетсЯ завершение
работы процесса;

</li><li>процесс может игнорировать сигнал. …сли процесс игнорирует
сигнал, то сигнал не оказывает на процесс никакого воздействиЯ
(учтите, что SIGCONT, SIGSTOP и SIGKILL не могут быть игнорированы в
обычных обстоЯтельствах);

</li><li>процесс может предусмотреть <em>обработчик сигнала</em> - функцию,
котораЯ будет вызыватьсЯ при приеме сигнала. …сли процесс содержит
обработчик длЯ какого-либо сигнала, говорЯт, что процесс может
"поймать" этот сигнал. ‹юбой процесс, который "ловит" сигнал,
фактически получает особый вид программного прерываниЯ. Ќикакие данные
с сигналом не передаютсЯ.</li></ul>

<p>‚ промежутке времени между моментом, когда сигнал
порожден, и моментом, когда он доставлен, сигнал называетсЯ ожидающим.
„лЯ процесса ожидающими одновременно могут быть несколько различных
сигналов. ‘игналы доставлЯютсЯ процессу, когда планировщик Ядра
делает этот процесс готовым к выполнению. Џроцесс не должен строить
никаких предположений относительно порЯдка, в котором будут
доставлены ожидающие сигналы.


<p><b><a name="id23">Џеречень сигналов</a></b>
<table border>
<tr><th>‘игнал:
</th><th>Ћписание:
</th></tr><tr><td>SIGABRT</td>
<td>‘игнал ненормального завершениЯ, порождаетсЯ функцией <i>abort()</i>.
</td></tr><tr><td>SIGALRM</td>
<td>‘игнал тайм-аута, порождаетсЯ функцией <i>alarm()</i>.
</td></tr><tr><td>SIGBUS</td>
<td>“казывает на ошибку контролЯ четности оперативной памЯти (особаЯ
длЯ QNX интерпретациЯ). …сли во времЯ выполнениЯ обработчика данного
сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
</td></tr><tr><td>SIGCHLD</td>
<td>‡авершение порожденного процесса. „ействие по умолчанию - игнорировать сигнал.
</td></tr><tr><td>SIGCONT</td>
<td>…сли процесс в состоЯнии HELD, то продолжить выполнение.
„ействие по умолчанию - игнорировать сигнал, если процесс не в
состоЯнии HELD.
</td></tr><tr><td>SIGDEV</td>
<td>ѓенерируетсЯ, когда в Њенеджере устройств происходит важное и
запрошенное событие.
</td></tr><tr><td>SIGFPE</td>
<td>ЋшибочнаЯ арифметическаЯ операциЯ (целочисленнаЯ или с плавающей
запЯтой), например, деление на ноль или операциЯ, вызвавшаЯ
переполнение. …сли во времЯ выполнениЯ обработчика данного сигнала
произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
</td></tr><tr><td>SIGHUP</td>
<td>ѓибель процесса, который был ведущим сеанса, или зависание
управлЯющего терминала.
</td></tr><tr><td>SIGILL</td>
<td>Ћбнаружение недопустимой аппаратной команды. …сли во времЯ
выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ
ошибка, то процесс будет завершен.
</td></tr><tr><td>SIGINT</td>
<td>€нтерактивный сигнал "внимание" (<b>Break</b>)
</td></tr><tr><td>SIGKILL</td>
<td>‘игнал завершениЯ - должен быть использован только в экстренных
ситуациЯх. <em>ќтот сигнал не может быть "пойман" или игнорирован</em>.
‘ервер может защитить себЯ от этого сигнала посредством функции Языка
‘и <i>qnx_pflags()</i>. „лЯ этого сервер должен иметь статус
привилегированного пользователЯ.
</td></tr><tr><td>SIGPIPE</td>
<td>Џопытка записи в программный канал, который не открыт длЯ чтениЯ.
</td></tr><tr><td>SIGPWR</td>
<td>Џерезапуск компьютера в результате нажатиЯ <b>Ctrl</b>-<b>Alt</b>-<b>Shift</b>-<b>Del</b> или вызова утилиты <tt>shutdown</tt>.
</td></tr><tr><td>SIGQUIT</td>
<td>€нтерактивный сигнал завершениЯ.
</td></tr><tr><td>SIGSEGV</td>
<td>Ћбнаружение недопустимой ссылки на оперативную памЯть. …сли во
времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ
ошибка, то процесс будет завершен.
</td></tr><tr><td>SIGSTOP
”ункциЯ Языка ‘и:	Ќазначение:
Send()	посылка сообщений
Receive()	получение сообщений
Reply()	ответ процессу, пославшему сообщение
…сли процесс выдал:	’о процесс:
‡апрос Send(), и отправленное им сообщение еще не получено процессом-получателем	SEND-блокирован
‡апрос Send(), и отправленное им сообщение получено процессом-получателем, но ответ еще не выдан	REPLY-блокирован
‡апрос Receive(), но еще не получил сообщение	RECEIVE-блокирован
‡арезервированный диапазон:	Ћписание:
`0x0000` - `0x00FF`	‘ообщениЯ Њенеджера процессов
`0x0100` - `0x01FF`	‘ообщениЯ ввода/вывода (общие длЯ всех серверов ввода/вывода)
`0x0200` - `0x02FF`	‘ообщениЯ Њенеджера файловой системы
`0x0300` - `0x03FF`	‘ообщениЯ Њенеджера устройств
`0x0400` - `0x04FF`	‘ообщениЯ Њенеджера сети
`0x0500` - `0x0FFF`	‡арезервированы длЯ будущих системных процессов QNX
…сли вы хотите:	€спользуйте:
Џородить сигнал из командной строки	“тилиты: `kill` и `slay`
Џородить сигнал внутри процесса	”ункции ‘и: kill() и raise()
‘игнал:	Ћписание:
SIGABRT	‘игнал ненормального завершениЯ, порождаетсЯ функцией abort().
SIGALRM	‘игнал тайм-аута, порождаетсЯ функцией alarm().
SIGBUS	“казывает на ошибку контролЯ четности оперативной памЯти (особаЯ длЯ QNX интерпретациЯ). …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGCHLD	‡авершение порожденного процесса. „ействие по умолчанию - игнорировать сигнал.
SIGCONT	…сли процесс в состоЯнии HELD, то продолжить выполнение. „ействие по умолчанию - игнорировать сигнал, если процесс не в состоЯнии HELD.
SIGDEV	ѓенерируетсЯ, когда в Њенеджере устройств происходит важное и запрошенное событие.
SIGFPE	ЋшибочнаЯ арифметическаЯ операциЯ (целочисленнаЯ или с плавающей запЯтой), например, деление на ноль или операциЯ, вызвавшаЯ переполнение. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGHUP	ѓибель процесса, который был ведущим сеанса, или зависание управлЯющего терминала.
SIGILL	Ћбнаружение недопустимой аппаратной команды. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGINT	€нтерактивный сигнал "внимание" (Break)
SIGKILL	‘игнал завершениЯ - должен быть использован только в экстренных ситуациЯх. ќтот сигнал не может быть "пойман" или игнорирован. ‘ервер может защитить себЯ от этого сигнала посредством функции Языка ‘и qnx_pflags(). „лЯ этого сервер должен иметь статус привилегированного пользователЯ.
SIGPIPE	Џопытка записи в программный канал, который не открыт длЯ чтениЯ.
SIGPWR	Џерезапуск компьютера в результате нажатиЯ Ctrl-Alt-Shift-Del или вызова утилиты `shutdown`.
SIGQUIT	€нтерактивный сигнал завершениЯ.
SIGSEGV	Ћбнаружение недопустимой ссылки на оперативную памЯть. …сли во времЯ выполнениЯ обработчика данного сигнала произойдет втораЯ такаЯ ошибка, то процесс будет завершен.
SIGSTOP