HelenOS-docHelenOSHelenOS-historic

Català-Valencià – Catalan中文 – Chinese (Simplified)中文 – Chinese (Traditional)Česky – CzechDansk – DanishNederlands – DutchEnglish – EnglishSuomi – FinnishFrançais – FrenchDeutsch – Germanעברית – Hebrewहिंदी – HindiMagyar – HungarianBahasa Indonesia – IndonesianItaliano – Italian日本語 – Japanese한국어 – KoreanМакедонски – Macedonianमराठी – MarathiNorsk – NorwegianPolski – PolishPortuguês – PortuguesePortuguês – Portuguese (Brazil)Русский – RussianSlovenčina – SlovakSlovenščina – SlovenianEspañol – SpanishSvenska – SwedishTürkçe – TurkishУкраїнська – UkrainianOëzbekcha – Uzbek

Compare Revisions

• This comparison shows the changes necessary to convert path

  → /design/trunk/src/ch_ipc.xml @ 113

  → /design/trunk/src/ch_ipc.xml @ 114

  ↔ Reverse comparison

• Compare Path:	Rev

  With Path:	Rev

Ignore whitespace Rev 113 → Rev 114

/design/trunk/src/ch_ipc.xml
81,6 → 81,24
</listitem>
</itemizedlist>
<figure float="1">
<mediaobject id="ipc1">
<imageobject role="pdf">
<imagedata fileref="images/ipc1.pdf" format="PDF" />
</imageobject>
<imageobject role="html">
<imagedata fileref="images/ipc1.png" format="PNG" />
</imageobject>
<imageobject role="fop">
<imagedata fileref="images/ipc1.svg" format="SVG" />
</imageobject>
</mediaobject>
<title>Low level IPC</title>
</figure>
<para>The communication between task A, that is connected to task B
looks as follows: Task A sends a message over it's phone to the target
asnwerbox. The message is saved in task B incoming call queue. When task
105,7 → 123,7
connection ("hangs his phone up").</para>
<para>When a task dies (whether voluntarily or by being killed), cleanup
process is started. </para>
process is started.</para>
<orderedlist>
<listitem>
140,7 → 158,7
services closely related to the inter-process communication. A range of
method numbers is allocated and protocol is defined for these functions.
The messages are interpreted by the kernel layer and appropriate actions
are taken depending on the parameters of message and answer. </para>
are taken depending on the parameters of message and answer.</para>
<para>The kernel provides the following services:</para>
169,7 → 187,7
the recepient of this message answers with an accepting answer, a new
connection is created. In itself, this mechanism would allow only
duplicating existing connection. However, if the message is forwarded,
the new connection is made to the final recipient. </para>
the new connection is made to the final recipient.</para>
<para>On startup every task is automatically connect to the name service
task, which acts as a switchboard and forwards requests for connection
182,7 → 200,7
<para>Tasks can share their address space areas using IPC messages. The
2 message types - AS_AREA_SEND and AS_AREA_RECV are used for sending and
receiving an address area respectively. The shared area can be accessed
as soon as the message is acknowledged. </para>
as soon as the message is acknowledged.</para>
</section>
</section>
210,7 → 228,26
messages from the answerbox and puts them into appropriate queues of
running tasks. If a task waiting for a message is not running, the
control is transferred to it.</para>
<figure float="1">
<mediaobject id="ipc2">
<imageobject role="pdf">
<imagedata fileref="images/ipc2.pdf" format="PDF" />
</imageobject>
<imageobject role="html">
<imagedata fileref="images/ipc2.png" format="PNG" />
</imageobject>
<imageobject role="fop">
<imagedata fileref="images/ipc2.svg" format="SVG" />
</imageobject>
</mediaobject>
<title>Single point of entry</title>
</figure>
<para>Very similar situation arises when a task decides to send a lot of
messages and reaches kernel limit of asynchronous messages. In such
situation 2 remedies are available - the userspace liberary can either