9,8 → 9,8 |
reliability of IPC model and implementation. Although theoretically the use |
of asynchronous messaging system looks promising, it is not often |
implemented because of a problematic implementation of end user |
applications. HelenOS implements a fully asynchronous messaging system but |
with a special layer providing a user application developer a reasonably |
applications. HelenOS implements a fully asynchronous messaging system with |
a special layer providing a user application developer a reasonably |
synchronous multithreaded environment sufficient to develop complex |
protocols.</para> |
|
49,8 → 49,8 |
|
<para>The whole IPC subsystem consists of one-way communication |
channels. Each task has one associated message queue (answerbox). The |
task can open connections (identified by phone id) to other tasks, send |
and forward messages through these connections and answer received |
task can call other tasks and connect it's phones to their answerboxes., |
send and forward messages through these connections and answer received |
messages. Every sent message is identified by a unique number, so that |
the response can be later matched against it. The message is sent over |
the phone to the target answerbox. Server application periodically |
61,23 → 61,51 |
of the open phones to another task. This mechanism is used e.g. for |
opening new connections.</para> |
|
<para>The answerbox contains four different message queues:</para> |
|
<itemizedlist> |
<listitem> |
<para>Incoming call queue</para> |
</listitem> |
|
<listitem> |
<para>Dispatched call queue</para> |
</listitem> |
|
<listitem> |
<para>Answer queue</para> |
</listitem> |
|
<listitem> |
<para>Notification queue</para> |
</listitem> |
</itemizedlist> |
|
<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 |
B fetches the message for processing, it is automatically moved into the |
dispatched call queue. After the server decides to answer the message, |
it is removed from dispatched queue and the result is moved into the |
answer queue of task A.</para> |
|
<para>The arguments contained in the message are completely arbitrary |
and decided by the user. The low level part of kernel IPC fills in |
appropriate error codes if there is an error during communication. It is |
ensured that the applications are correctly notified about communication |
state. If the outgoing connection is closed with the hangup message, the |
target answerbox receives a hangup message. The connection |
identification is not reused, until the hangup message is acknowledged |
and all other pending messages are answered.</para> |
assured that the applications are correctly notified about communication |
state. If a program closes the outgoing connection, the target answerbox |
receives a hangup message. The connection identification is not reused, |
until the hangup message is acknowledged and all other pending messages |
are answered.</para> |
|
<para>If the server side decides to hangup an incoming connection, it |
does it by responding to any incoming message with an EHANGUP error |
code. The connection is then immediately closed. The client connection |
identification (phone id) is not reused, until the client issues hangup |
system call to close the outgoing connection.</para> |
<para>Closing an incoming connection is done by responding to any |
incoming message with an EHANGUP error code. The connection is then |
immediately closed. The client connection identification (phone id) is |
not reused, until the client issues closes it's own side of the |
connection ("hangs his phone up").</para> |
|
<para>When a task dies (whether voluntarily or by being killes), cleanup |
process is started which performs following tasks.</para> |
<para>When a task dies (whether voluntarily or by being killed), cleanup |
process is started. </para> |
|
<orderedlist> |
<listitem> |
133,6 → 161,28 |
<para>Asking for an address space area</para> |
</listitem> |
</itemizedlist> |
|
<para>On startup every task is automatically connected to a |
<emphasis>name service task</emphasis>, which provides a switchboard |
functionality. To open a new outgoing connection, the client sends a |
<constant>CONNECT_ME_TO</constant> message using any of his phones. If |
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> |
|
<para>On startup every task is automatically connect to the name service |
task, which acts as a switchboard and forwards requests for connection |
to specific services. To be able to forward a message it must have a |
phone connected to the service tasks. The task creates this connection |
using a <constant>CONNECT_TO_ME</constant> message which creates a |
callback connection. Every service that wants to receive connections |
asks name service task to create a callback connection.</para> |
|
<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> |
</section> |
</section> |
|
185,7 → 235,7 |
</section> |
|
<section> |
<title>Synchronization problem</title> |
<title>Ordering problem</title> |
|
<para>Unfortunately, in the real world is is never so easy. E.g. if a |
server handles incoming requests and as a part of it's response sends |