| 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 |