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 |