| 21,20 → 21,29 |
|---|
| the corresponding platforms), from which the first one is considered a |
| method number on message receipt and a return value on answer receipt. The |
| received message contains identification of the incoming connection, so |
| that it can distinguish the messages between different senders. Internally |
| the message contains pointer to the originating task and to the source of |
| the communication channel. If the message is forwarded, the originating |
| task identifies the recipient of the answer, the source channel identifies |
| connection in case of a hangup message.</para> |
| that the receiving application can distinguish the messages between |
| different senders. Internally the message contains pointer to the |
| originating task and to the source of the communication channel. If the |
| message is forwarded, the originating task identifies the recipient of the |
| answer, the source channel identifies the connection in case of a hangup |
| response.</para> |
| |
| <para>Every message must be eventually answered. The system keeps track of |
| all messages, so that it can answer them with appropriate error code |
| should one of the connection parties fail unexpectedly. To limit buffering |
| of messages in the kernel, every process is limited in a number of |
| asynchronous messages it may have unanswered simultanously. If the limit |
| is reached, the kernel refuses to send any other message, until some of |
| the active messages are answered.</para> |
| of the messages in the kernel, every process is has a limited account of |
| asynchronous messages it can send simultanously. If the limit is reached, |
| the kernel refuses to send any other message, until some active message is |
| answered.</para> |
| |
| <para>To facilitate kernel-to-user communication, the IPC subsystem |
| provides notification messages. The applications can subscribe to a |
| notification channel and receive messages directed to this channel. Such |
| messages can be freely sent even from interrupt context as they are |
| primarily destined to deliver IRQ events to userspace device drivers. |
| These messages need not be answered, there is no party that could receive |
| such response.</para> |
| |
| <section> |
| <title>Low level IPC</title> |
| |
| 47,20 → 56,83 |
|---|
| the phone to the target answerbox. Server application periodically |
| checks the answerbox and pulls messages from several queues associated |
| with it. After completing the requested action, server sends a reply |
| back to the answerbox of the originating task. </para> |
| back to the answerbox of the originating task. If a need arises, it is |
| possible to <emphasis>forward</emphasis> a recevied message throught any |
| of the open phones to another task. This mechanism is used e.g. for |
| opening new connections.</para> |
| |
| <para>If a need arises, it is possible to <emphasis>forward</emphasis> a |
| recevied message throught any of the open phones to another task. This |
| mechanism is used e.g. for opening new connections.</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> |
| |
| <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>When a task dies (whether voluntarily or by being killes), cleanup |
| process is started which performs following tasks.</para> |
| |
| <orderedlist> |
| <listitem> |
| <para>Hangs up all outgoing connections and sends hangup messages to |
| all target answerboxes.</para> |
| </listitem> |
| |
| <listitem> |
| <para>Disconnects all incoming connections.</para> |
| </listitem> |
| |
| <listitem> |
| <para>Disconnects from all notification channels.</para> |
| </listitem> |
| |
| <listitem> |
| <para>Answers all unanswered messages from answerbox queues with |
| appropriate error code.</para> |
| </listitem> |
| |
| <listitem> |
| <para>Waits until all outgoing messages are answered and all |
| remaining answerbox queues are empty.</para> |
| </listitem> |
| </orderedlist> |
| </section> |
| |
| <section> |
| <title>Services for user application</title> |
| <title>System call IPC layer</title> |
| |
| <para>On top of this simple protocol the kernel provides special |
| services including opening new connection to other tasks, offering |
| callback connections and sending and receiving address space areas. |
| </para> |
| 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> |
| |
| <para>The kernel provides the following services:</para> |
| |
| <itemizedlist> |
| <listitem> |
| <para>Creating new outgoing connection</para> |
| </listitem> |
| |
| <listitem> |
| <para>Creating a callback connection</para> |
| </listitem> |
| |
| <listitem> |
| <para>Sending an address space area</para> |
| </listitem> |
| |
| <listitem> |
| <para>Asking for an address space area</para> |
| </listitem> |
| </itemizedlist> |
| </section> |
| </section> |
| |
| 72,7 → 144,7 |
|---|
| However, by intensive utilization of user-space threads, it was possible |
| to create an environment that is not necesarilly restricted to this type |
| of event-driven programming and allows for more fluent expression of |
| application programs. </para> |
| application programs.</para> |
| |
| <section> |
| <title>Single point of entry</title> |
| 87,7 → 159,7 |
|---|
| control is transfered to this manager task. The manager tasks pops |
| 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> |
| control is transferred to it.</para> |
| |
| <para>Very similar situation arises when a task decides to send a lot of |
| messages and reaches kernel limit of asynchronous messages. In such |
| 124,8 → 196,8 |
|---|
| answer couldn't be ever processed. The IPC framework allows a developer |
| to specify, that the thread should not be preempted to any other thread |
| (except notification handlers) while still being able to queue messages |
| belonging to other threads and regain control when the answer arrives. |
| </para> |
| belonging to other threads and regain control when the answer |
| arrives.</para> |
| |
| <para>This mechanism works transparently in multithreaded environment, |
| where classical locking mechanism (futexes) should be used. The IPC |