WebSVN – HelenOS-doc – Diff – /design/trunk/src/ch_ipc.xml

   protocols.</para>
   <section>
     <title>Kernel Services</title>
-    <para>Every message consists of four numeric arguments (32-bit and 64-bit on
+    <para>Every message consists of four numeric arguments (32-bit and 64-bit
-    the corresponding platforms), from which the first one is considered a
+    on 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 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
         </mediaobject>
       </figure>
       <para>The communication between task A, that is connected to task B
       looks as follows: task A sends a message over its phone to the target
-      asnwerbox. The message is saved in task B's incoming call queue. When task
+      asnwerbox. The message is saved in task B's incoming call queue. When
-      B fetches the message for processing, it is automatically moved into the
+      task B fetches the message for processing, it is automatically moved
-      dispatched call queue. After the server decides to answer the message,
+      into the dispatched call queue. After the server decides to answer the
-      it is removed from dispatched queue and the result is moved into the
+      message, it is removed from dispatched queue and the result is moved
-      answer queue of task A.</para>
+      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
       assured that the applications are correctly notified about communication
       are answered.</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 closes its own side of the
+      not reused, until the client closes its own side of the connection
-      connection ("hangs his phone up").</para>
+      ("hangs his phone up").</para>
       <para>When a task dies (whether voluntarily or by being killed), cleanup
       process is started.</para>
       <orderedlist>
       <title>System Call IPC Layer</title>
       <para>On top of this simple protocol the kernel provides special
       services closely related to the inter-process communication. A range of
       method numbers is allocated and protocol is defined for these functions.
-      These messages are interpreted by the kernel layer and appropriate actions
+      These messages are interpreted by the kernel layer and appropriate
-      are taken depending on the parameters of the message and the answer.</para>
+      actions are taken depending on the parameters of the message and the
+      answer.</para>
       <para>The kernel provides the following services:</para>
       <itemizedlist>
         <listitem>
         </listitem>
       </itemizedlist>
       <para>On startup, every task is automatically connected to a
       <emphasis>naming service task</emphasis>, which provides a switchboard
-      functionality. In order to open a new outgoing connection, the client sends a
+      functionality. In order to open a new outgoing connection, the client
-      <constant>CONNECT_ME_TO</constant> message using any of his phones. If
+      sends a <constant>CONNECT_ME_TO</constant> message using any of his
-      the recepient of this message answers with an accepting answer, a new
+      phones. If the recepient of this message answers with an accepting
-      connection is created. In itself, this mechanism would allow only
+      answer, a new connection is created. In itself, this mechanism would
-      duplicating existing connection. However, if the message is forwarded,
+      allow only duplicating existing connection. However, if the message is
-      the new connection is made to the final recipient.</para>
+      forwarded, the new connection is made to the final recipient.</para>
-      <para>In order for a task to be able to forward a message, it
+      <para>In order for a task to be able to forward a message, it must have
-      must have a phone connected to the destination task.
+      a phone connected to the destination task. The destination task
-      The destination task establishes such connection by sending the <constant>CONNECT_TO_ME</constant>
+      establishes such connection by sending the
-      message to the forwarding task. A callback connection is opened afterwards.
+      <constant>CONNECT_TO_ME</constant> message to the forwarding task. A
-      Every service that wants to receive connections
+      callback connection is opened afterwards. Every service that wants to
-      has to ask the naming service to create the callback connection via this mechanism.</para>
+      receive connections has to ask the naming service to create the callback
+      connection via this mechanism.</para>
       <para>Tasks can share their address space areas using IPC messages. The
-      two message types - <constant>AS_AREA_SEND</constant> and <constant>AS_AREA_RECV</constant> are used for sending and
+      two message types - <constant>AS_AREA_SEND</constant> and
+      <constant>AS_AREA_RECV</constant> are used for sending and receiving an
-      receiving an address space area respectively. The shared area can be accessed
+      address space area respectively. The shared area can be accessed as soon
-      as soon as the message is acknowledged.</para>
+      as the message is acknowledged.</para>
     </section>
   </section>
   <section>
     <title>Userspace View</title>
     <para>The conventional design of the asynchronous API seems to produce
     applications with one event loop and several big switch statements.
-    However, by intensive utilization of userspace pseudo threads, it was possible
+    However, by intensive utilization of userspace fibrils, it was possible to
-    to create an environment that is not necessarily restricted to this type
+    create an environment that is not necessarily restricted to this type of
-    of event-driven programming and allows for more fluent expression of
+    event-driven programming and allows for more fluent expression of
     application programs.</para>
     <section>
       <title>Single Point of Entry</title>
       <para>Each task is associated with only one answerbox. If a
-      multithreaded application needs to communicate, it must be not only
+      multithreaded application needs to communicate, it must be not only able
-      able to send a message, but it should be able to retrieve the answer as
+      to send a message, but it should be able to retrieve the answer as well.
-      well. If several pseudo threads pull messages from task answerbox, it is a
+      If several fibrils pull messages from task answerbox, it is a matter of
-      matter of coincidence, which thread receives which message. If a particular
+      coincidence, which fibril receives which message. If a particular fibril
-      thread needs to wait for a message answer, an idle
+      needs to wait for a message answer, an idle <emphasis>manager</emphasis>
-      <emphasis>manager</emphasis> pseudo thread is found or a new one is created and
+      fibril is found or a new one is created and control is transfered to
-      control is transfered to this manager thread. The manager threads pop
+      this manager fibril. The manager fibrils pop messages from the answerbox
-      messages from the answerbox and put them into appropriate queues of
+      and put them into appropriate queues of running fibrils. If a fibril
-      running threads. If a pseudo thread waiting for a message is not running, the
+      waiting for a message is not running, the control is transferred to
-      control is transferred to it.</para>
+      it.</para>
       <figure float="1">
         <title>Single point of entry</title>
         <mediaobject id="ipc2">
           <imageobject role="pdf">
             <imagedata fileref="images/ipc2.pdf" format="PDF" />
           </imageobject>
           <imageobject role="fop">
             <imagedata fileref="images/ipc2.svg" format="SVG" />
           </imageobject>
         </mediaobject>
       </figure>
       <para>Very similar situation arises when a task decides to send a lot of
       messages and reaches the kernel limit of asynchronous messages. In such
       situation, two remedies are available - the userspace library can either
       cache the message locally and resend the message when some answers
-      arrive, or it can block the thread and let it go on only after the
+      arrive, or it can block the fibril and let it go on only after the
       message is finally sent to the kernel layer. With one exception, HelenOS
-      uses the second approach - when the kernel responds that the maximum limit
+      uses the second approach - when the kernel responds that the maximum
-      of asynchronous messages was reached, the control is transferred to a manager
+      limit of asynchronous messages was reached, the control is transferred
-      pseudo thread. The manager thread then handles incoming replies and, when space
+      to a manager fibril. The manager fibril then handles incoming replies
-      is available, sends the message to the kernel and resumes the application thread
+      and, when space is available, sends the message to the kernel and
-      execution.</para>
+      resumes the application fibril execution.</para>
       <para>If a kernel notification is received, the servicing procedure is
-      run in the context of the manager pseudo thread. Although it wouldn't be
+      run in the context of the manager fibril. Although it wouldn't be
       impossible to allow recursive calling, it could potentially lead to an
-      explosion of manager threads. Thus, the kernel notification procedures
+      explosion of manager fibrils. Thus, the kernel notification procedures
       are not allowed to wait for a message result, they can only answer
       messages and send new ones without waiting for their results. If the
       kernel limit for outgoing messages is reached, the data is automatically
       cached within the application. This behaviour is enforced automatically
       and the decision making is hidden from the developer.</para>
       <figure float="1">
         <title>Single point of entry solution</title>
         <mediaobject id="ipc3">
           <imageobject role="pdf">
             <imagedata fileref="images/ipc3.pdf" format="PDF" />
           </imageobject>
           <imageobject role="fop">
             <imagedata fileref="images/ipc3.svg" format="SVG" />
           </imageobject>
         </mediaobject>
       </figure>
     </section>
     <section>
       <title>Ordering Problem</title>
       start intervening. This can happen even if the application utilizes only
       one userspace thread. Classical synchronization using semaphores is not
       possible as locking on them would block the thread completely so that
       the answer couldn't be ever processed. The IPC framework allows a
       developer to specify, that part of the code should not be preempted by
-      any other pseudo thread (except notification handlers) while still being able
+      any other fibril (except notification handlers) while still being able
-      to queue messages belonging to other pseudo threads and regain control when the
+      to queue messages belonging to other fibrils and regain control when the
       answer arrives.</para>
       <para>This mechanism works transparently in multithreaded environment,
       where additional locking mechanism (futexes) should be used. The IPC
-      framework ensures that there will always be enough free userspace threads
+      framework ensures that there will always be enough free userspace
-      to handle incoming answers and allow the application to run more
+      threads to handle incoming answers and allow the application to run more
-      pseudo threads inside the usrspace threads without the danger of
+      fibrils inside the userspace threads without the danger of locking all
-      locking all userspace threads in futexes.</para>
+      userspace threads in futexes.</para>
     </section>
     <section>
       <title>The Interface</title>
       the kernel limit, the flow of application is stopped until some answers
       arrive. On the other hand, server applications are expected to work in a
       multithreaded environment.</para>
       <para>The server interface requires the developer to specify a
-      <function>connection_thread</function> function. When new connection is
+      <function>connection_fibril</function> function. When new connection is
-      detected, a new pseudo thread is automatically created and control is
+      detected, a new fibril is automatically created and control is
       transferred to this function. The code then decides whether to accept
       the connection and creates a normal event loop. The userspace IPC
-      library ensures correct switching between several pseudo threads
+      library ensures correct switching between several threads within the
-      within the kernel environment.</para>
+      kernel environment.</para>
     </section>
   </section>
 </chapter>

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ch_ipc.xml – Rev 169 → 171