Sistemnaya arhitektura QNX4

---------------------------------------------------------------
     (S) QNX Software Systems Ltd., 1996
     Avtor: QNX Software Systems Ltd.
     Russkoe izdanie: 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>
Vpervye na russkom yazyke kniga o QNX.
Rob Kerten "Vvedenie v QNX/Neutrino 2". <a href=http://www.swd.ru/qnx/support/literature/5-94656-025-9.html>Annotaciya</a>,
<a href=http://www.swd.ru/qnx/support/literature/request/>Zakaz pechatnoj versii(400 r.)</a></td></tr></table></div>

<h1><a name="id1">Sistemnaya arhitektura QNX4</a></h1>


<p>Kniga <cite>Sistemnaya arhitektura</cite> soprovozhdaet operacionnuyu
sistemu QNX i prednaznachena kak dlya razrabotchikov prilozhenij, tak i dlya
konechnyh pol'zovatelej.
<p>V knige podrobno rassmatrivaetsya struktura i funkcii
QNX. V nej opisany mikroyadro, sistemnye menedzhery, a takzhe unikal'nyj
mehanizm svyazi mezhdu processami, osnovannyj  na peredache soobshchenij.
Prezhde chem ispol'zovat' QNX, rekomenduetsya snachala prochitat' etu knigu.

<p>Za informaciej ob ustanovke i ispol'zovanii QNX,
obratites' k knige <cite>Rukovodstvo pol'zovatelya</cite> OS QNX
<p><em>Sistemnaya arhitektura</em> soderzhit sleduyushchie glavy:
<ul>
<li> <a href="#p1">Koncepciya QNX;</a></li>
<li> <a href="#p2">Mikroyadro;</a></li>
<li> <a href="#p3">Menedzher processov;</a></li>
<li> <a href="#p4">Prostranstvo imen vvoda/vyvoda;</a></li>
<li> <a href="#p5">Menedzher fajlovoj sistemy;</a></li>
<li> <a href="#p6">Menedzher ustrojstv;</a></li>
<li> <a href="#p7">Menedzher seti;</a></li>
<li> <a href="#p8">Okonnaya sistema Photon microGUI.</a></li>
</ul>



<!-- 1  -->
<br><br>
<a name="p1">&nbsp;</a>
<h2>Koncepciya QNX</h2>

<p>|ta glava ohvatyvaet sleduyushchie temy:
<ul><li><a href="#WHATISQNX">chto takoe QNX?;
</a></li><li><a href="#MICROKERNELARCHITECTURE">arhitektura mikroyadra;
</a></li><li><a href="#IPC">svyaz' mezhdu processami (IPC);
</a></li><li><a href="#QNXASANETWORK">QNX kak set'.
</a></li></ul>


<h3><a name="WHATISQNX">CHto takoe QNX?
</a></h3>
<p>Glavnaya obyazannost' operacionnoj sistemy sostoit v upravlenii
resursami komp'yutera. Vse dejstviya v sisteme - dispetcherizaciya
prikladnyh programm, zapis' fajlov na disk, peresylka dannyh po seti i
t.p. - dolzhny vypolnyat'sya sovmestno nastol'ko slitno i prozrachno,
naskol'ko eto vozmozhno.

<p>Nekotorye oblasti primeneniya pred®yavlyayut bolee zhestkie trebovaniya
k upravleniyu resursami i dispetcherizacii programm, chem drugie.
Prilozheniya real'nogo vremeni, naprimer, polagayutsya na sposobnost'
operacionnoj sistemy obrabatyvat' mnogochislennye sobytiya v predelah
ogranichennogo intervala vremeni. CHem bystree reagiruet operacionnaya
sistema, tem bol'shee prostranstvo dlya manevra imeet prilozhenie
real'nogo vremeni v predelah zhestkih vremennyh ramok.

<p>Operacionnaya sistema QNX ideal'na dlya prilozhenij real'nogo
vremeni. Ona obespechivaet vse neot®emlemye sostavlyayushchie sistemy
real'nogo vremeni:  mnogozadachnost', dispetcherizaciyu programm na
osnove prioritetov i bystroe pereklyuchenie konteksta.

<p>QNX - udivitel'no gibkaya sistema. Razrabotchiki legko mogut
nastroit' operacionnuyu sistemu takim obrazom, chtoby ona otvechala
trebovaniyam konkretnyh prilozhenij. QNX pozvolyaet vam sozdat' sistemu,
ispol'zuyushchuyu tol'ko neobhodimye dlya resheniya vashej zadachi resursy.
Konfiguraciya sistemy mozhet izmenyat'sya v shirokom diapazone - ot yadra s
neskol'kimi nebol'shimi modulyami do polnocennoj setevoj sistemy,
obsluzhivayushchej sotni pol'zovatelej.

<p>QNX dostigaet svoego unikal'nogo urovnya proizvoditel'nosti,
modul'nosti i prostoty blagodarya dvum fundamental'nym principam:

<ul><li> arhitektura na osnove mikroyadra;
</li><li> svyaz' mezhdu processami na osnove soobshchenij.
</li></ul>

<h3><a name="MICROKERNELARCHITECTURE">Arhitektura mikroyadra sistemy QNX</a></h3>
<p>QNX sostoit iz nebol'shogo yadra, koordiniruyushchego rabotu
vzaimodejstvuyushchih processov. Kak pokazano na risunke, struktura bol'she
napominaet ne ierarhiyu, a komandu, v kotoroj neskol'ko igrokov odnogo
urovnya vzaimodejstvuyut mezhdu soboj i so svoim "zashchitnikom" - yadrom.

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

<p><i>Mikroyadro sistemy QNX koordiniruet rabotu sistemnyh menedzherov.</i>
<pre>

</pre>

<p><b><a name="id4">Nastoyashchee yadro</a></b>
<p><em>YAdro</em> - eto "serdce" lyuboj operacionnoj sistemy.
V nekotoryh operacionnyh sistemah na nego vozlagaetsya tak mnogo
funkcij, chto yadro, po suti, zamenyaet vsyu operacionnuyu sistemu!

<p>V QNX zhe Mikroyadro - eto nastoyashchee yadro. Vo-pervyh, kak i sleduet
yadru real'nogo vremeni, yadro QNX imeet ochen' malen'kij razmer.
Vo-vtoryh, ono vypolnyaet dve vazhnejshie funkcii:

<ul><li><b>peredacha soobshchenij</b> - Mikroyadro  obespechivaet
marshrutizaciyu vseh soobshchenij mezhdu vsemi processami v sisteme;
</li><li><b>dispetcherizaciya</b> - planirovshchik - eto chast'
Mikroyadra, i on poluchaet upravlenie vsyakij raz, kogda process izmenyaet
svoe sostoyanie v rezul'tate polucheniya soobshcheniya ili preryvaniya.

</li></ul><p>V otlichie ot vseh ostal'nyh processov, yadro nikogda ne poluchaet
upravleniya v rezul'tate dispetcherizacii.  Vhodyashchij v sostav yadra kod
vypolnyaetsya tol'ko v rezul'tate pryamyh vyzovov iz processa ili
apparatnogo preryvaniya.


<p><b><a name="id5">Sistemnye processy</a></b>
<p>Vse uslugi operacionnoj sistemy,  za  isklyucheniem  teh,  kotorye
vypolnyayutsya  yadrom,  v QNX predostavlyayutsya cherez standartnye processy.
Tipichnaya konfiguraciya QNX imeet sleduyushchie sistemnye processy:

<ul><li> Menedzher processov (<tt>Proc</tt>);</li>
<li> Menedzher fajlovoj sistemy (<tt>Fsys</tt>);</li>
<li> Menedzher ustrojstv (<tt>Dev</tt>);</li>
<li> Menedzher seti (<tt>Net</tt>).</li></ul>
<h3><a name="id6">Sistemnye i pol'zovatel'skie processy</a></h3>
<p>Sistemnye processy prakticheski nichem ne otlichayutsya ot lyubyh
napisannyh pol'zovatelem programm - oni ne imeyut kakogo-libo skrytogo
ili osobogo interfejsa, nedostupnogo pol'zovatel'skim processam.

<p>Imenno za schet takoj sistemnoj arhitektury QNX obladaet
unikal'noj narashchivaemost'yu. Tak kak bol'shinstvo uslug operacionnoj
sistemy predostavlyayutsya standartnymi processami QNX, to rasshirenie
operacionnoj sistemy trebuet vsego lish' napisaniya novoj programmy,
obespechivayushchej novuyu uslugu!

<p>Fakticheski, granica mezhdu operacionnoj sistemoj i prikladnoj
programmoj mozhet byt' ochen' razmyta. Edinstvennyj kriterij, po kotoromu
my mozhem otlichit' prikladnye processy i sistemnye servisnye processy,
sostoit v tom, chto process operacionnoj sistemy upravlyaet kakim-libo
resursom v interesah prikladnogo processa.

<p>Predpolozhim, chto vy napisali server bazy dannyh. Kak zhe dolzhen
byt' klassificirovan etot process?

<p>Tochno tak zhe, kak server fajlovoj sistemy prinimaet zaprosy (v QNX
realizovannye cherez mehanizm soobshchenij) na otkrytie fajlov i zapis'
ili chtenie dannyh, eto budet delat' i server bazy dannyh. Hotya zaprosy
k serveru bazy dannyh mogut byt' i bolee slozhnymi, shodstvo oboih
serverov zaklyuchaetsya v tom, chto oba oni obespechivayut dostup k resursu
posredstvom zaprosov.  Oba oni yavlyayutsya nezavisimymi processami,
kotorye mogut byt' napisany pol'zovatelem i zapuskat'sya po mere
neobhodimosti.

<p>Server bazy dannyh mozhet rassmatrivat'sya kak process v odnom
sluchae i kak prilozhenie v drugom. <em>|to dejstvitel'no ne imeet
znacheniya!</em> Vazhno to, chto sozdanie i vypolnenie takih processov v QNX ne
trebuet absolyutno nikakih izmenenij v standartnyh komponentah
operacionnoj sistemy.


<h3><a name="id7">Drajvery ustrojstv</a></h3>
<p>Drajvery ustrojstv - eto processy, kotorye yavlyayutsya posrednikami
mezhdu operacionnoj sistemoj i ustrojstvami i izbavlyayut operacionnuyu
sistemu ot neobhodimosti imet' delo s osobennostyami konkretnyh
ustrojstv.

<p>Tak kak drajvery zapuskayutsya kak obychnye processy, dobavlenie
novogo drajvera v QNX ne vliyaet na drugie chasti operacionnoj sistemy.
Takim obrazom, dobavlenie novogo drajvera v QNX ne trebuet nichego,
krome neposredstvenno zapuska etogo drajvera.

<p>Posle zapuska i zaversheniya procedury inicializacii, drajver mozhet
vybrat' odin iz dvuh variantov povedeniya:

<ul><li>stat' rasshireniem opredelennogo sistemnogo processa;
</li><li>prodolzhat' vypolnenie kak nezavisimyj process.
</li></ul>

<h3><a name="IPC">Svyaz' mezhdu processami (IPC)</a></h3>
<p>V tipichnoj dlya mnogozadachnoj sistemy real'nogo vremeni situacii,
kogda neskol'ko processov vypolnyayutsya odnovremenno, operacionnaya
sistema dolzhna predostavit' mehanizmy, pozvolyayushchie im obshchat'sya drug s
drugom.

<p>Svyaz' mezhdu processami (Interprocess communication, sokrashchenno
IPC) yavlyaetsya klyuchom k razrabotke prilozhenij kak sovokupnosti
processov, v kotoryh kazhdyj process vypolnyaet otvedennuyu emu chast'
obshchej zadachi.

<p>QNX predostavlyaet prostoj, no moshchnyj nabor vozmozhnostej IPC,
kotorye sushchestvenno oblegchayut razrabotku prilozhenij, sostoyashchih iz
vzaimodejstvuyushchih processov.


<p><b><a name="id9">Peredacha soobshchenij</a></b>
<p>QNX byla pervoj kommercheskoj operacionnoj sistemoj svoego klassa,
kotoraya ispol'zovala peredachu soobshchenij v kachestve osnovnogo sposoba
IPC. Imenno posledovatel'noe voploshchenie metoda peredachi soobshcheniya v
masshtabah vsej operacionnoj sistemy obuslovlivaet moshchnost', prostotu i
elegantnost' QNX.

<p>Soobshcheniya v QNX - eto posledovatel'nost' bajt, peredavaemyh ot
odnogo processa drugomu. Operacionnaya sistema ne pytaetsya
analizirovat' soderzhanie soobshcheniya - peredavaemye dannye imeyut smysl
tol'ko dlya otpravitelya i poluchatelya, i ni dlya kogo bolee.

<p>Peredacha soobshcheniya pozvolyaet ne tol'ko obmenivat'sya dannymi, no i
yavlyaetsya sposobom sinhronizacii vypolneniya neskol'kih processov. Kogda
oni posylayut, poluchayut ili otvechayut na soobshcheniya, processy
preterpevayut razlichnye "izmeneniya sostoyaniya", kotorye vliyayut na to,
kogda i kak dolgo oni mogut vypolnyat'sya.  Znaya sostoyaniya i prioritety
processov, yadro organizuet ih dispetcherizaciyu takim obrazom, chtoby
maksimal'no effektivno ispol'zovat' resursy central'nogo processora
(CP).

<p>Prilozhenie real'nogo vremeni i drugie otvetstvennye prilozheniya po
pravu nuzhdayutsya v nadezhnom mehanizme peredachi soobshchenij, t.k. vhodyashchie
v sostav etih prilozhenij processy tesno vzaimosvyazany. Realizovannyj v
QNX  mehanizm peredachi soobshchenij sposobstvuet uporyadocheniyu i povysheniyu
nadezhnosti programm.


<h3><a name="QNXASANETWORK">QNX kak set'</a></h3>
<p>V prostejshem sluchae lokal'naya set' obespechivaet razdelyaemyj
dostup k fajlam i periferijnym ustrojstvam dlya neskol'kih soedinennyh
mezhdu soboj komp'yuterov. QNX idet gorazdo dal'she etogo prostejshego
predstavleniya i ob®edinyaet vsyu set' v edinyj odnorodnyj nabor
resursov.

<p>Lyuboj process na lyubom komp'yutere v sostave seti mozhet
neposredstvenno ispol'zovat' lyuboj resurs na lyubom drugom komp'yutere.
S tochki zreniya prilozhenij, ne sushchestvuet nikakoj raznicy mezhdu mestnym
ili udalennym resursom, i ispol'zovanie udalennyh resursov ne trebuet
kakih-libo special'nyh sredstv.  Bolee togo, chtoby opredelit',
nahoditsya li takoj resurs kak fajl ili ustrojstvo na lokal'nom
komp'yutere ili na drugom uzle seti, v programmu potrebuetsya vklyuchit'
special'nyj dopolnitel'nyj kod!

<p>Pol'zovateli mogut imet' dostup k fajlam po vsej seti,
ispol'zovat' lyuboe periferijnoe ustrojstvo, zapuskat' programmy na
lyubom komp'yutere seti (pri uslovii, chto oni imeyut nadlezhashchie
polnomochiya). Svyaz' mezhdu processami osushchestvlyaetsya edinoobrazno,
nezavisimo ot ih mestopolozheniya v seti.  V osnove takoj prozrachnoj
podderzhki seti v QNX lezhit vseob®emlyushchaya koncepciya IPC na osnove
peredachi soobshchenij.


<p><b><a name="id11">Model' edinogo komp'yutera</a></b>
<p>QNX iznachal'no proektirovalsya kak setevaya operacionnaya sistema. V
nekotoryh otnosheniyah QNX set' napominaet skoree bol'shuyu |VM, nezheli
nabor mini-komp'yuterov. Pol'zovatelyam izvestno, chto v rasporyazhenii
lyuboj iz prikladnyh programm imeetsya bol'shoj nabor resursov. No v
otlichie ot bol'shoj |VM, QNX obespechivaet bystruyu reakciyu sistemy, t.k.
sootvetstvuyushchij ob®em vychislitel'nyh resursov mozhet byt' vydelen na
kazhdom uzle v sootvetstvii s potrebnostyami kazhdogo pol'zovatelya.

<p>V usloviyah upravleniya proizvodstvom ispol'zuyutsya programmiruemye
kontrollery i drugie ustrojstva vvoda/vyvoda, a takzhe kompleksy programm,
rabotayushchie v rezhime real'nogo vremeni, kotorym mozhet potrebovat'sya bol'she
resursov, chem drugim menee otvetstvennym prilozheniyam, takim kak tekstovyj
redaktor. Set' QNX dostatochno "otzyvchiva", chtoby podderzhivat'
<em>odnovremenno</em> oba etih tipa prilozhenij, QNX pozvolyaet sfokusirovat'
vychislitel'nuyu moshchnost' sistemy na proizvodstvennom oborudovanii (tam, gde
eto neobhodimo), v to zhe vremya, ne zhertvuya interfejsom pol'zovatelya.


<p><b><a name="id12">Gibkaya podderzhka seti</a></b>
<p>QNX set' mozhet byt' postroena s ispol'zovaniem razlichnogo
oborudovaniya i standartnyh promyshlennyh protokolov. V silu svoej
polnoj prozrachnosti dlya prikladnyh programm i pol'zovatelej, novye
setevye arhitektury mogut byt' vnedreny v lyuboe vremya, ne razrushaya
operacionnoj sistemy.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>Spisok podderzhivaemogo QNX setevogo oborudovaniya popolnyaetsya so
vremenem. Dlya polucheniya podrobnoj informacii obratites' k dokumentacii
na setevoe oborudovanie, kotoroe vy ispol'zuete.

</td>
</table>
<hr>

<p>Kazhdomu uzlu QNX seti prisvaivaetsya unikal'nyj nomer, kotoryj
stanovitsya ego identifikatorom. |tot nomer takzhe edinstvennyj vidimyj
priznak togo, funkcioniruet QNX kak set' ili kak odnoprocessornaya
operacionnaya sistema.

<p>Takaya stepen' prozrachnosti yavlyaetsya eshche odnim primerom bol'shih
vozmozhnostej arhitektury QNX, osnovannoj na peredache soobshchenij. Vo
mnogih operacionnyh sistemah takie vazhnye funkcii kak podderzhka seti,
IPC ili dazhe peredacha soobshchenij vypolneny v vide nadstroek nad
operacionnoj sistemoj, a ne integrirovany neposredstvenno v ee
serdcevinu. Rezul'tatom takogo podhoda yavlyaetsya neuklyuzhij i
neeffektivnyj interfejs s "dvojnym standartom", kogda svyaz' mezhdu
processami - eto odno delo, v to vremya kak proniknovenie v skrytyj
interfejs tainstvennogo monolitnogo yadra - sovershenno drugoe delo!

<p>QNX, naprotiv, ishodit iz togo, chto effektivnaya svyaz' yavlyaetsya
klyuchom k effektivnoj rabote. Peredacha soobshchenij yavlyaetsya, takim obrazom,
kraeugol'nym kamnem arhitektury QNX, uvelichivaet effektivnost' <em>vseh
bez isklyucheniya</em> tranzakcij mezhdu processami v sisteme, nezavisimo ot
togo, idet li rech' o peredache dannyh po vnutrennej shine personal'nogo
komp'yutera ili po koaksial'nomu kabelyu na rasstoyanie neskol'kih mil'.

<p>Teper' davajte perejdem k bolee podrobnomu rassmotreniyu struktury
QNX.




<!-- 1  -->





<!-- 2  -->


<h2><a name="p2">Mikroyadro</a></h2>

<p>|ta glava ohvatyvaet sleduyushchie temy:
<ul><li><a href="#INTRO">vvedenie;
</a></li><li><a href="#KERNELIPC">svyaz' mezhdu processami (IPC);
</a></li><li><a href="#IPCMESSAGES">IPC posredstvom soobshchenij;
</a></li><li><a href="#IPCPROXIES">IPC posredstvom proksi;
</a></li><li><a href="#IPCSIGNALS">IPC posredstvom signalov;
</a></li><li><a href="#IPCNET">IPC v seti;
</a></li><li><a href="#IPCSEM">IPC posredstvom semaforov;
</a></li><li><a href="#SCHEDULING">dispetcherizaciya processov;
</a></li><li><a href="#REALTIMEPERFORMANCE">neskol'ko slov o real'nom vremeni.
</a> </li></ul>


<h3><a name="INTRO">Vvedenie</a></h3>
<p>Mikroyadro QNX otvechaet za vypolnenie sleduyushchih funkcij:
<ul><li>svyaz' mezhdu processami - Mikroyadro upravlyaet marshrutizaciej
<em>soobshchenij</em>; ono takzhe podderzhivaet dve drugie formy IPC -
<em>proksi</em> i <em>signaly</em>;

</li><li>setevoj interfejs nizkogo urovnya - Mikroyadro osushchestvlyaet
dostavku vseh soobshchenij, prednaznachennyh dlya processov na drugih uzlah
seti;

</li><li>dispetcherizaciya processov - vhodyashchij v sostav YAdra
<em>planirovshchik</em> reshaet, kakomu iz zapushchennyh processov dolzhno byt'
peredano upravlenie;

</li><li>pervichnaya obrabotka preryvanij - vse apparatnye preryvaniya i
isklyucheniya snachala prohodyat cherez Mikroyadro, a zatem peredayutsya
sootvetstvuyushchemu drajveru ili sistemnomu menedzheru.

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

<p><i>Vnutri mikroyadra QNX.</i>
<pre>

</pre>

<h3><a name="KERNELIPC">Svyaz' mezhdu processami</a></h3>
<p>Mikroyadro QNX podderzhivaet tri vazhnejshie formy svyazi mezhdu
processami: soobshcheniya, proksi i signaly.

<ul><li><em>Soobshcheniya</em> - eto osnovopolagayushchaya forma IPC v QNX.
Oni obespechivayut sinhronnuyu svyaz' mezhdu vzaimodejstvuyushchimi processami,
kogda processu, posylayushchemu soobshchenie, trebuetsya poluchit'
podtverzhdenie togo, chto ono polucheno i, vozmozhno, otvet.

</li><li><em>Proksi</em> - eto osobyj vid soobshcheniya. Oni bol'she vsego
podhodyat dlya izveshcheniya o nastuplenii kakogo-libo sobytiya, kogda processu,
posylayushchemu soobshchenie, ne trebuetsya vstupat' v dialog s poluchatelem.

</li><li><em>Signaly</em> - eto tradicionnaya forma IPC. Oni
ispol'zuyutsya dlya asinhronnoj svyazi mezhdu processami.

</li></ul>

<h3><a name="IPCMESSAGES">IPC posredstvom soobshchenij</a></h3>
<p>Soobshcheniya v QNX - eto pakety bajt, kotorye sinhronno
peredayutsya ot odnogo processa k drugomu. QNX pri etom ne  analiziruet
soderzhanie soobshcheniya. Peredavaemye dannye ponyatny tol'ko otpravitelyu i
poluchatelyu i nikomu bolee.


<p><b><a name="id5">Primitivy peredachi soobshchenij</a></b>
<p>Dlya neposredstvennoj svyazi drug s drugom vzaimodejstvuyushchie
processy ispol'zuyut sleduyushchie funkcii yazyka programmirovaniya Si:

<table border>
<tr><th>Funkciya yazyka Si:
</th><th>Naznachenie:
</th></tr><tr><td><i>Send()</i></td><td>posylka soobshchenij
</td></tr><tr><td><i>Receive()</i></td><td>poluchenie soobshchenij
</td></tr><tr><td><i>Reply()</i></td><td>otvet processu, poslavshemu soobshchenie
</td></tr></table>
<p>|ti funkcii mogut byt' ispol'zovany kak lokal'no,  t.e. dlya svyazi
mezhdu processami na odnom komp'yutere,  tak i v predelah seti, t.e. dlya
svyazi mezhdu processami na raznyh uzlah.

<p>Sleduet zametit', odnako, chto daleko ne vsegda voznikaet
neobhodimost' ispol'zovat' funkcii <i>Send()</i>, <i>Receive()</i> i
<i>Reply()</i> v yavnom vide. Biblioteka funkcij yazyka Si v QNX postroena
na osnove ispol'zovaniya soobshchenij - v rezul'tate, kogda process ispol'zuet
standartnye mehanizmy peredachi dannyh (takie, kak, naprimer, programmnyj
kanal - pipe), on kosvennym obrazom ispol'zuet peredachu soobshchenij.

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

<p><i>Process A posylaet soobshchenie processu B, kotoryj poluchaet ego,
obrabatyvaet i posylaet otvet</i>

<pre>

</pre>

<p>Na risunke izobrazhena posledovatel'nost' sobytij, imeyushchih mesto,
kogda dva processa, process A i process B, ispol'zuyut funkcii
<i>Send()</i>, <i>Receive()</i> i <i>Reply()</i> dlya svyazi drug s drugom:


<ol>
<li> Process A posylaet soobshchenie processu B, vyzvav funkciyu <i>Send()</i>,
kotoraya peredaet sootvetstvuyushchij zapros yadru. V etot moment vremeni
process  A perehodit v SEND-blokirovannoe sostoyanie i ostaetsya v etom
sostoyanii do teh por, poka process B ne vyzovet funkciyu <i>Receive()</i>
dlya polucheniya soobshcheniya.

</li><li> Process B vyzyvaet <i>Receive()</i> i poluchaet soobshchenie ot
processa A. Pri etom sostoyanie processa A izmenyaetsya na REPLY-blokirovan.
Process B pri vyzove funkcii <i>Receive()</i> v dannom sluchae ne blokiruetsya,
t.k. k etomu momentu ego uzhe ozhidalo soobshchenie ot processa A.

<p>Zamet'te, chto esli by process B vyzval <i>Receive()</i> do togo, kak
emu bylo poslano soobshchenie, to on by popal v sostoyanie RECEIVE-blokirovan do
polucheniya soobshcheniya. V etom sluchae process-otpravitel' soobshcheniya
nemedlenno posle posylki soobshcheniya popal by v sostoyanie
REPLY-blokirovan.
</li><li> Process B vypolnyaet obrabotku poluchennogo ot processa A
soobshcheniya i zatem vyzyvaet funkciyu <i>Reply()</i>. Otvetnoe soobshchenie
peredaetsya processu A, kotoryj perehodit v sostoyanie gotovnosti k
vypolneniyu. Vyzov <i>Reply()</i> ne blokiruet process B, kotoryj takzhe gotov
k vypolneniyu. Kakoj iz etih processov budet vypolnyat'sya, zavisit ot ih
prioritetov.
</li></ol>


<p><b><a name="id6">Sinhronizaciya processov</a></b>
<p>Peredacha soobshchenij ne tol'ko pozvolyaet processam obmenivat'sya
dannymi, no i predostavlyaet mehanizm sinhronizacii vypolneniya
neskol'kih vzaimodejstvuyushchih processov.

<p>Davajte snova rassmotrim privedennyj vyshe risunok. Posle togo kak
process A vyzval funkciyu <i>Send()</i>, on ne mozhet prodolzhat' vypolnenie
do teh por, poka ne poluchit otvet na poslannoe soobshchenie. |to
garantiruet, chto vypolnyaemaya processom B po zaprosu processa A
obrabotka dannyh budet zavershena prezhde, chem process A prodolzhit
vypolnenie. Bolee togo, posle vyzova processom B zaprosa na poluchenie
dannyh <i>Receive()</i>, on ne mozhet prodolzhat' vypolnenie do teh por,
poka ne poluchit sleduyushchee soobshchenie.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>Bolee podrobno dispetcherizaciya processov v QNX rassmatrivaetsya v
razdele "<a href="#SCHEDULING">Dispetcherizaciya processov</a>"
dalee v etoj glave.
</td>
</table>
<hr>

<p><b><a name="id7">Blokirovannye sostoyaniya</a></b>
<p>Kogda processu ne razreshaetsya prodolzhat' vypolnenie, t.k. on
dolzhen ozhidat' okonchaniya opredelennoj stadii protokola peredachi
soobshcheniya, - process nazyvaetsya <em>blokirovannym</em>.

<p>Vozmozhnye blokirovannye sostoyaniya processov privedeny v sleduyushchej
tablice:

<table border>
<tr><th>Esli process vydal:
</th><th>To process:
</th></tr><tr><td>Zapros <i>Send()</i>, i otpravlennoe im soobshchenie eshche ne polucheno processom-poluchatelem
</td><td>SEND-blokirovan
</td></tr><tr><td>Zapros <i>Send()</i>, i otpravlennoe im soobshchenie polucheno processom-poluchatelem, no otvet eshche ne vydan
</td><td>REPLY-blokirovan
</td></tr><tr><td>Zapros <i>Receive()</i>, no eshche ne poluchil soobshchenie
</td><td>RECEIVE-blokirovan
</td></tr></table>
<p><hr>
<p><img src="qnx4-states.gif" alt="fig: i/states.gif">
<hr>

<p><i>Izmenenie sostoyaniya processov v tipichnom sluchae peredachi soobshcheniya.</i>
<pre>

</pre>


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>Dlya polucheniya informacii obo vseh vozmozhnyh sostoyaniyah processa smotri
glavu "<a href="#p3">Menedzher processov</a>".
</td>
</table>
<hr>

<p><b><a name="id8">Ispol'zovanie <i>Send()</i>, <i>Receive()</i> i <i>Reply()</i></a></b>
<p>Davajte teper' bolee podrobno rassmotrim vyzovy funkcij <i>Send()</i>,
<i>Receive()</i> i <i>Reply()</i>. Vospol'zuemsya rassmotrennym vyshe
primerom peredachi soobshcheniya ot processa A k processu B.


<h3><a name="id9">Funkciya <i>Send()</i></a></h3>
<p>Predpolozhim, chto process A vydaet zapros na peredachu soobshcheniya
processu V. |to vypolnyaetsya posredstvom vyzova funkcii
<i>Send()</i>:


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

<p>Pri vyzove funkcii <i>Send()</i> ispol'zuyutsya sleduyushchie argumenty:
<dl>
<dt><i>pid</i></dt>
<dd>identifikator processa (<em>p</em>rocess <em>ID</em>), kotoromu
prednaznachaetsya soobshchenie (t.e. processa B); etot identifikator
ispol'zuetsya dlya obrashcheniya k processu so storony operacionnoj
sistemy i drugih processov;
</dd><dt><i>smsg</i></dt>
<dd>bufer soobshcheniya (t.e. soobshchenie, podlezhashchee posylke)
</dd><dt><i>rmsg</i></dt>
<dd>bufer otveta (budet soderzhat' otvet ot processa B)
</dd><dt><i>smsg_len</i></dt>
<dd>dlina posylaemogo soobshcheniya v bajtah
</dd><dt><i>rmsg_len</i></dt>
<dd>maksimal'naya dlina otveta, kotoryj mozhet prinyat' process A, v bajtah
</dd></dl>
<p>Obratite vnimanie, chto budet peredano ne bolee <i>smsg_len</i> bajt i
ne bolee chem <i>rmsg_len</i> bajt budet polucheno v kachestve otveta - eto
garantiruet, chto ne proizojdet sluchajnogo perepolneniya buferov.


<h3><a name="id10">Funkciya <i>Receive()</i></a></h3>
<p>Vyzvav zapros <i>Receive()</i>, process B mozhet poluchit' soobshchenie,
napravlennoe emu processom A:


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

<p>Vyzov funkcii <i>Receive()</i> soderzhit sleduyushchie argumenty:
<dl>
<dt><i>pid</i></dt>
<dd>identifikator processa, kotoryj poslal soobshchenie (t.e. process A)
</dd><dt><tt>0</tt></dt>
<dd>(nol') oznachaet, chto process B zhelaet prinyat' soobshchenie ot lyubogo
processa
</dd><dt><i>msg</i></dt>
<dd>bufer, kuda budet pomeshcheno prinimaemoe soobshchenie
</dd><dt><i>msg_len</i></dt>
<dd>maksimal'nyj razmer dannyh, kotorye budut pomeshcheny v bufer priema, v bajtah
</dd></dl>
<p>Esli znacheniya argumentov <i>smsg_len</i> v vyzove funkcii <i>Send()</i>
i <i>msg_len</i> v vyzove funkcii <i>Receive()</i> otlichayutsya, drug ot
druga, to naimen'shee iz nih opredelyaet razmer dannyh, kotorye budut
peredany.


<h3><a name="id11">Funkciya <i>Reply()</i></a></h3>
<p>Posle uspeshnogo polucheniya soobshcheniya ot processa A, process B
dolzhen otvetit' processu A, vyzvav funkciyu <i>Reply()</i>:


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

<p>Vyzov funkcii <i>Reply()</i> soderzhit sleduyushchie argumenty:
<dl compact>
<dt><i>pid</i></dt>
<dd>identifikator processa, kotoromu prednaznachaetsya otvet (t.e. process A)
</dd><dt><i>reply</i></dt>
<dd>bufer, soderzhashchij otvet
</dd><dt><i>reply_len</i></dt>
<dd>dlina dannyh, peredavaemyh v kachestve otveta, v bajtah
</dd></dl>
<p>Esli znacheniya argumentov <i>reply_len</i> pri vyzove
funkcii <i>Reply()</i> i <i>rmsg_len</i> pri vyzove
funkcii <i>Send()</i> otlichayutsya drug ot druga, to
naimen'shee iz nih opredelyaet razmer peredavaemyh dannyh.


<p><b><a name="id12">Reply-upravlyaemyj obmen soobshcheniyami</a></b>
<p>Primer obmena soobshcheniyami, kotoryj my tol'ko chto rassmotreli,
illyustriruet naibolee rasprostranennyj sluchaj ispol'zovaniya soobshchenij
- sluchaj, kogda dlya processa, vypolnyayushchego funkcii servera, normal'nym
yavlyaetsya sostoyanie RECEIVE-blokirovan v ozhidanii kakih-libo zaprosov
klienta.  |to nazyvaetsya <em>send-upravlyaemyj obmen soobshcheniyami</em>:
process-klient iniciiruet dejstvie, posylaya soobshcheniya, otvet servera na
soobshchenie zavershaet dejstvie.

<p>Sushchestvuet i drugaya model' obmena soobshcheniyami, ne stol'
rasprostranennaya, kak rassmotrennaya vyshe, hotya v nekotoryh situaciyah
ona dazhe bolee predpochtitel'na: <em>reply-upravlyaemyj obmen</em>
soobshcheniyami, pri kotorom dejstvie iniciiruetsya vyzovom funkcii
<i>Reply()</i>. V etom sluchae process-"rabotnik" posylaet serveru
soobshchenie, govoryashchee o tom, chto on gotov k rabote. Server ne otvechaet
srazu, a "zapominaet", chto rabotnik gotov vypolnit' ego zadanie.
V posledstvii server mozhet iniciirovat' dejstvie, otvetiv ozhidayushchemu
zadanie rabotniku. Process-rabotnik vypolnit zadanie i zavershit
dejstvie, poslav serveru soobshchenie, soderzhashchee rezul'taty svoej raboty.


<p><b><a name="id13">Dopolnitel'nye svedeniya</a></b>
<p>Pri razrabotke programm, ispol'zuyushchih peredachu soobshchenij,
neobhodimo imet' v vidu sleduyushchee:
<ul><li>soobshchenie sohranyaetsya v tele posylayushchego processa do teh por,
poka prinimayushchij process ne budet gotov poluchit' ego. Soobshchenie <em>ne</em>
kopiruetsya v Mikroyadro. |to bezopasno, t.k. posylayushchij process
SEND-blokirovan i ne mozhet neumyshlenno izmenit' soderzhimoe soobshcheniya

</li><li>pri vyzove funkcii <i>Reply()</i> dannye kopiruyutsya
iz otvechayushchego processa v REPLY-blokirovannyj process kak odna nerazryvnaya
operaciya. Vyzov funkcii <i>Reply()</i> ne blokiruet
process - REPLY-blokirovannyj process perestaet byt' blokirovannym posle
togo, kak v nego skopirovany dannye;

</li><li>pri posylke soobshcheniya processu ne trebuetsya znat' sostoyanie
togo processa, kotoromu eto soobshchenie adresovano. Esli poluchatel' ne
gotov k priemu soobshcheniya v moment ego otpravki, to posylayushchij soobshchenie
process prosto stanovitsya SEND-blokirovan;

</li><li>esli eto neobhodimo, to process mozhet posylat' soobshchenie
nulevoj dliny, otvet nulevoj dliny, libo i to i drugoe;

</li><li>s tochki zreniya razrabotchika, ispol'zovanie <i>Send()</i> dlya
peredachi processu-serveru zaprosa na poluchenie kakoj-libo uslugi
ravnoznachno vyzovu bibliotechnoj podprogrammy, predostavlyayushchej tu zhe
samuyu uslugu. V oboih sluchayah vasha programma snachala podgotavlivaet
opredelennye dannye, a zatem vyzyvaet libo funkciyu <i>Send()</i>, libo
bibliotechnuyu podprogrammu, posle chego ozhidaet, kogda oni zakonchat
vypolnenie. V oboih sluchayah kod, realizuyushchij zaprashivaemuyu uslugu,
vypolnyaetsya mezhdu dvumya chetko opredelennymi tochkami - <i>Receive()</i> i
<i>Reply()</i> dlya processa-servera, vhodom v podprogrammu i komandoj
<tt>return</tt> dlya vyzova bibliotechnoj podprogrammy. Kogda vyzyvaemaya
servisnaya programma zavershena, vasha programma "znaet", kuda pomeshcheny
rezul'taty, i mozhet pristupit' k proverke vozvrashchennogo koda oshibki,
obrabotke rezul'tatov i tak dalee.

<p>Nesmotrya na takuyu kazhushchuyusya prostotu, vyzov funkcii <i>Send()</i>
delaet gorazdo bol'she, chem prostoj vyzov bibliotechnoj podprogrammy.
Funkciya <i>Send()</i> mozhet prozrachno dlya vyzyvayushchej programmy peredat'
zapros na drugoj uzel seti, gde i budet v dejstvitel'nosti vypolnyat'sya
obsluzhivayushchij zapros kod. Pri etom takzhe mozhet byt' zadejstvovana
parallel'naya obrabotka dannyh bez izderzhek na sozdanie novogo
processa. Process-server mozhet srazu, kak tol'ko stanet vozmozhnym,
vyzvat' funkciyu <i>Reply()</i>, pozvolyaya tem samym zaprashivavshemu processu
vozobnovit' vypolnenie i, v to zhe vremya, prodolzhit' vypolnenie samomu.

</li><li>vozmozhna situaciya, kogda soobshcheniya ot mnogih processov
odnovremenno ozhidayut svoej obrabotki odnim i tem zhe prinimayushchim
processom. Kak pravilo, prinimayushchij process poluchaet soobshchenie v tom
zhe poryadke, v kakom oni byli poslany drugimi processami; odnako
prinimayushchij process mozhet ustanovit' ocherednost' polucheniya soobshchenij
na osnove prioritetov posylayushchih processov.

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

<p><i>Server poluchil soobshchenie ot klienta A i klienta B (no eshche ne
otvetil im). Soobshcheniya ot klientov C, D, E eshche ne polucheny.</i>

<pre>

</pre>

<p><b><a name="ADVANCEDFAC">Dopolnitel'nye vozmozhnosti</a></b>
<p>QNX takzhe predostavlyaet sleduyushchie dopolnitel'nye vozmozhnosti po
peredache soobshchenij:

<ul><li>uslovnyj priem soobshchenij;
</li><li>chtenie ili zapis' chasti soobshchenij;
</li><li>sostavnye soobshcheniya (soobshcheniya, sostoyashchie iz neskol'kih chastej).
</li></ul>
<h3><a name="id15">Uslovnyj priem soobshchenij</a></h3>
<p>Obychno, kogda process hochet prinyat' soobshchenie, on vyzyvaet
funkciyu <i>Receive()</i> dlya ozhidaniya prihoda soobshcheniya. |to obychnyj
sposob polucheniya soobshchenij, kotoryj prigoden v bol'shinstve sluchaev.

<p>Odnako vozmozhna situaciya, kogda processu neobhodimo opredelit',
imeyutsya li ozhidayushchie priema soobshcheniya, ne popadaya pri etom v sostoyanie
RECEIVE-blokirovan v sluchae ih otsutstviya. Naprimer, processu
trebuetsya oprashivat' rabotayushchee s vysokoj skorost'yu ustrojstvo,
kotoroe ne sposobno generirovat' preryvanie, i v to zhe vremya on dolzhen
otvechat' na soobshcheniya ot drugih processov. V etom sluchae process mozhet
ispol'zovat' funkciyu <i>Creceive()</i>, kotoraya libo prochitaet ozhidayushchee
priema soobshchenie, libo nemedlenno vernet upravlenie processu v sluchae
otsutstviya ozhidayushchih priema soobshchenij.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>Sleduet po vozmozhnosti izbegat' ispol'zovaniya funkcii
<i>Creceive()</i>, t.k. ona pozvolyaet processu nepreryvno vypolnyat'sya
s neizmenyayushchimsya urovnem prioriteta.
</td>
</table>
<hr>


<h3><a name="id16">CHtenie ili zapis' chasti soobshcheniya</a></h3>
<p>Inogda zhelatel'no chitat' ili zapisyvat' soobshcheniya po chastyam s
tem, chtoby ispol'zovat' uzhe vydelennyj dlya soobshcheniya bufer vmesto
vydeleniya otdel'nogo rabochego bufera.

<p>Naprimer, menedzher vvoda/vyvoda mozhet prinimat' dannye v vide
soobshchenij, kotorye sostoyat iz zagolovka fiksirovannoj dliny i
sleduyushchih za nim dannyh peremennoj dliny. V zagolovke ukazyvaetsya
razmer dannyh (ot 0 do 64 Kbajt). V etom sluchae menedzher
vvoda/vyvoda mozhet snachala prinyat' tol'ko zagolovok soobshcheniya, a zatem
ispol'zovat' funkciyu <i>Readmsg()</i> dlya chteniya dannyh peremennoj dliny
neposredstvenno v sootvetstvuyushchij bufer vyvoda. Esli razmer dannyh
prevyshaet razmer bufera, to menedzher mozhet neodnokratno vyzyvat'
funkciyu <i>Readmsg()</i> po mere osvobozhdeniya bufera vyvoda. Analogichnym
obrazom, funkciya <i>Writemsg()</i> mozhet byt' ispol'zovana dlya poetapnogo
kopirovaniya dannyh v vydelennyj dlya otvetnogo soobshcheniya bufer
neposredstvenno v tele processa, poslavshego soobshchenie, umen'shaya, takim
obrazom, potrebnost' menedzhera vvoda/vyvoda v vydelenii vnutrennih
buferov.


<h3><a name="id17">Sostavnye soobshcheniya</a></h3>
<p>Do sih por my rassmatrivali soobshcheniya kak nepreryvnuyu
posledovatel'nost' bajt. Odnako soobshcheniya chasto sostoyat iz dvuh ili
bolee otdel'nyh chastej. Naprimer, soobshchenie mozhet imet' zagolovok
fiksirovannoj dliny, za kotorym sleduyut dannye peremennoj dliny. Dlya
togo chtoby izbezhat' kopirovaniya chastej takogo soobshcheniya vo vremennye
promezhutochnye bufery pri peredache ili prieme, mozhet byt' ispol'zovano
sostavnoe soobshchenie, sostoyashchee iz dvuh ili bolee otdel'nyh buferov
soobshchenij. Imenno blagodarya etoj vozmozhnosti menedzhery vvoda/vyvoda
QNX, takie kak <tt>Dev</tt> i <tt>Fsys</tt>, dostigayut svoej vysokoj
proizvoditel'nosti.

<p>Sleduyushchie funkcii pozvolyayut obrabatyvat' sostavnye soobshcheniya:

<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>Sostavnye soobshcheniya mogut byt' opisany s pomoshch'yuqqq¸0 special'noj mx
struktury. Mikroyadro ob®edinyaet chasti takogo soobshcheniya v edinyj
nepreryvnyj potok dannyh.</i>
<pre>

</pre>

<p><b><a name="id18">Zarezervirovannye kody soobshchenij</a></b>
<p>QNX nachinaet vse soobshcheniya s 16-ti bitnogo slova, nazyvaemogo
<em>kodom soobshcheniya</em>. Zametim, odnako, chto eto ne yavlyaetsya
obyazatel'nym dlya vas trebovaniem pri napisanii sobstvennyh programm.
QNX ispol'zuet kody soobshchenij v sleduyushchih diapazonah:

<table border>
<tr><th>Zarezervirovannyj diapazon:
</th><th>Opisanie:
</th></tr><tr><td><tt>0x0000</tt> - <tt>0x00FF</tt></td>
<td>Soobshcheniya Menedzhera processov
</td></tr><tr><td><tt>0x0100</tt> - <tt>0x01FF</tt></td>
<td>Soobshcheniya vvoda/vyvoda (obshchie dlya vseh serverov vvoda/vyvoda)
</td></tr><tr><td><tt>0x0200</tt> - <tt>0x02FF</tt></td>
<td>Soobshcheniya Menedzhera fajlovoj sistemy
</td></tr><tr><td><tt>0x0300</tt> - <tt>0x03FF</tt></td>
<td>Soobshcheniya Menedzhera ustrojstv
</td></tr><tr><td><tt>0x0400</tt> - <tt>0x04FF</tt></td>
<td>Soobshcheniya Menedzhera seti
</td></tr><tr><td><tt>0x0500</tt> - <tt>0x0FFF</tt></td>
<td>Zarezervirovany dlya budushchih sistemnyh processov QNX
</td></tr></table>


<h3><a name="IPCPROXIES">IPC posredstvom proksi</a></h3>
<p><em>Proksi</em> - eto forma neblokiruyushchego soobshcheniya, osobenno
podhodyashchego dlya izveshcheniya o nastuplenii sobytiya, kogda posylayushchij process
ne nuzhdaetsya v dialoge s poluchatelem. Edinstvennaya funkciya proksi sostoit
v posylke fiksirovannogo soobshcheniya opredelennomu processu, kotoryj
yavlyaetsya vladel'cem proksi.  Podobno soobshcheniyam, proksi mogut byt'
ispol'zovany v predelah vsej seti.

<p>Ispol'zuya proksi, process ili obrabotchik preryvaniya mozhet poslat'
soobshchenie drugomu processu, ne blokiruyas' i ne ozhidaya otveta.

<p>Vot nekotorye primery ispol'zovaniya proksi:

<ul><li>process zhelaet izvestit' drugoj process o nastuplenii
kakogo-libo sobytiya, no pri etom ne mozhet pozvolit' sebe posylku
soobshcheniya (v etom sluchae on ostavalsya by blokirovannym do teh
por, poka poluchatel' ne vyzovet <i>Receive()</i> i <i>Reply()</i>);

</li><li>process hochet poslat' dannye drugomu processu, no pri etom
emu ne trebuetsya ni otveta, ni kakogo-libo drugogo podtverzhdeniya togo,
chto adresat (poluchatel') poluchil soobshchenie;

</li><li>obrabotchik preryvaniya hochet izvestit' process o postuplenii
novyh dannyh.
</li></ul>

<p>Dlya sozdaniya proksi ispol'zuetsya funkciya yazyka Si
<i>qnx_proxy_attach()</i>. Lyuboj drugoj process ili obrabotchik preryvaniya,
kotoromu izvesten identifikator proksi, mozhet vospol'zovat'sya funkciej
yazyka Si <i>Trigger()</i> dlya togo, chtoby zastavit' proksi peredat'
zaranee zadannoe soobshchenie. Zapros <i>Trigger()</i> obrabatyvaetsya
Mikroyadrom.

<p>Proksi mozhet byt' "zapushcheno" neodnokratno - kazhdyj raz pri etom
ono posylaet soobshchenie. Proksi mozhet nakaplivat' ochered' dlinoj do
65535 soobshchenij.

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

<p><i>Process-klient zapuskaet proksi 3 raza,  v rezul'tate chego server
poluchaet 3 "konservirovannyh" soobshcheniya ot proksi.</i>
<pre>

</pre>


<h3><a name="IPCSIGNALS">IPC posredstvom signalov</a></h3>
<p>Signaly yavlyayutsya tradicionnym sposobom asinhronnoj svyazi, kotoraya
ispol'zuetsya v techenie mnogih let v razlichnyh operacionnyh sistemah.

<p>QNX podderzhivaet bol'shoj nabor signalov, sootvetstvuyushchih standartu
POSIX, krome togo, signaly, istoricheski prisushchie nekotorym UNIX-sistemam,
i ryad signalov, unikal'nyh dlya QNX.


<p><b><a name="id21">Kak porodit' signal</a></b>
<p>Schitaetsya, chto signal dostavlen processu togda, kogda vypolnyaetsya
opredelennoe v processe dlya dannogo signala dejstvie. Process mozhet
posylat' signal samomu sebe.

<table border>
<tr><th>Esli vy hotite:
</th><th>Ispol'zujte:
</th></tr><tr><td>Porodit' signal iz komandnoj stroki
</td><td>Utility: <tt>kill</tt> i <tt>slay</tt></td></tr>
<tr><td>Porodit' signal vnutri processa
</td><td>Funkcii Si: <i>kill()</i> i <i>raise()</i></td></tr></table>

<p><b><a name="id22">Poluchenie signalov</a></b>
<p>Process mozhet prinyat' signal odnim iz treh sposobov, v
zavisimosti ot togo, kak v processe opredelena obrabotka signalov:

<ul><li>esli process ne opredelil nikakih special'nyh mer po obrabotke
signala, to vypolnyaetsya predusmotrennoe dlya signala dejstvie po
umolchaniyu - obychno takim dejstviem po umolchaniyu yavlyaetsya zavershenie
raboty processa;

</li><li>process mozhet ignorirovat' signal. Esli process ignoriruet
signal, to signal ne okazyvaet na process nikakogo vozdejstviya
(uchtite, chto SIGCONT, SIGSTOP i SIGKILL ne mogut byt' ignorirovany v
obychnyh obstoyatel'stvah);

</li><li>process mozhet predusmotret' <em>obrabotchik signala</em> - funkciyu,
kotoraya budet vyzyvat'sya pri prieme signala. Esli process soderzhit
obrabotchik dlya kakogo-libo signala, govoryat, chto process mozhet
"pojmat'" etot signal. Lyuboj process, kotoryj "lovit" signal,
fakticheski poluchaet osobyj vid programmnogo preryvaniya. Nikakie dannye
s signalom ne peredayutsya.</li></ul>

<p>V promezhutke vremeni mezhdu momentom, kogda signal
porozhden, i momentom, kogda on dostavlen, signal nazyvaetsya ozhidayushchim.
Dlya processa ozhidayushchimi odnovremenno mogut byt' neskol'ko razlichnyh
signalov. Signaly dostavlyayutsya processu, kogda planirovshchik yadra
delaet etot process gotovym k vypolneniyu. Process ne dolzhen stroit'
nikakih predpolozhenij otnositel'no poryadka, v kotorom budut
dostavleny ozhidayushchie signaly.


<p><b><a name="id23">Perechen' signalov</a></b>
<table border>
<tr><th>Signal:
</th><th>Opisanie:
</th></tr><tr><td>SIGABRT</td>
<td>Signal nenormal'nogo zaversheniya, porozhdaetsya funkciej <i>abort()</i>.
</td></tr><tr><td>SIGALRM</td>
<td>Signal tajm-auta, porozhdaetsya funkciej <i>alarm()</i>.
</td></tr><tr><td>SIGBUS</td>
<td>Ukazyvaet na oshibku kontrolya chetnosti operativnoj pamyati (osobaya
dlya QNX interpretaciya). Esli vo vremya vypolneniya obrabotchika dannogo
signala proizojdet vtoraya takaya oshibka, to process budet zavershen.
</td></tr><tr><td>SIGCHLD</td>
<td>Zavershenie porozhdennogo processa. Dejstvie po umolchaniyu - ignorirovat' signal.
</td></tr><tr><td>SIGCONT</td>
<td>Esli process v sostoyanii HELD, to prodolzhit' vypolnenie.
Dejstvie po umolchaniyu - ignorirovat' signal, esli process ne v
sostoyanii HELD.
</td></tr><tr><td>SIGDEV</td>
<td>Generiruetsya, kogda v Menedzhere ustrojstv proishodit vazhnoe i
zaproshennoe sobytie.
</td></tr><tr><td>SIGFPE</td>
<td>Oshibochnaya arifmeticheskaya operaciya (celochislennaya ili s plavayushchej
zapyatoj), naprimer, delenie na nol' ili operaciya, vyzvavshaya
perepolnenie. Esli vo vremya vypolneniya obrabotchika dannogo signala
proizojdet vtoraya takaya oshibka, to process budet zavershen.
</td></tr><tr><td>SIGHUP</td>
<td>Gibel' processa, kotoryj byl vedushchim seansa, ili zavisanie
upravlyayushchego terminala.
</td></tr><tr><td>SIGILL</td>
<td>Obnaruzhenie nedopustimoj apparatnoj komandy. Esli vo vremya
vypolneniya obrabotchika dannogo signala proizojdet vtoraya takaya
oshibka, to process budet zavershen.
</td></tr><tr><td>SIGINT</td>
<td>Interaktivnyj signal "vnimanie" (<b>Break</b>)
</td></tr><tr><td>SIGKILL</td>
<td>Signal zaversheniya - dolzhen byt' ispol'zovan tol'ko v ekstrennyh
situaciyah. <em>|tot signal ne mozhet byt' "pojman" ili ignorirovan</em>.
Server mozhet zashchitit' sebya ot etogo signala posredstvom funkcii yazyka
Si <i>qnx_pflags()</i>. Dlya etogo server dolzhen imet' status
privilegirovannogo pol'zovatelya.
</td></tr><tr><td>SIGPIPE</td>
<td>Popytka zapisi v programmnyj kanal, kotoryj ne otkryt dlya chteniya.
</td></tr><tr><td>SIGPWR</td>
<td>Perezapusk komp'yutera v rezul'tate nazhatiya <b>Ctrl</b>-<b>Alt</b>-<b>Shift</b>-<b>Del</b> ili vyzova utility <tt>shutdown</tt>.
</td></tr><tr><td>SIGQUIT</td>
<td>Interaktivnyj signal zaversheniya.
</td></tr><tr><td>SIGSEGV</td>
<td>Obnaruzhenie nedopustimoj ssylki na operativnuyu pamyat'. Esli vo
vremya vypolneniya obrabotchika dannogo signala proizojdet vtoraya takaya
oshibka, to process budet zavershen.
</td></tr><tr><td>SIGSTOP