81,24 → 81,6 |
</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 |
123,7 → 105,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> |
158,7 → 140,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> |
|
187,7 → 169,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 |
200,7 → 182,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> |
|
228,26 → 210,7 |
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 |