Rev 112 | Rev 117 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
| Rev 112 | Rev 114 | ||
|---|---|---|---|
| Line 79... | Line 79... | ||
| 79 | <listitem> |
79 | <listitem> |
| 80 | <para>Notification queue</para> |
80 | <para>Notification queue</para> |
| 81 | </listitem> |
81 | </listitem> |
| 82 | </itemizedlist> |
82 | </itemizedlist> |
| 83 | 83 | ||
| - | 84 | <figure float="1"> |
|
| - | 85 | <mediaobject id="ipc1"> |
|
| - | 86 | <imageobject role="pdf"> |
|
| - | 87 | <imagedata fileref="images/ipc1.pdf" format="PDF" /> |
|
| - | 88 | </imageobject> |
|
| - | 89 | ||
| - | 90 | <imageobject role="html"> |
|
| - | 91 | <imagedata fileref="images/ipc1.png" format="PNG" /> |
|
| - | 92 | </imageobject> |
|
| - | 93 | ||
| - | 94 | <imageobject role="fop"> |
|
| - | 95 | <imagedata fileref="images/ipc1.svg" format="SVG" /> |
|
| - | 96 | </imageobject> |
|
| - | 97 | </mediaobject> |
|
| - | 98 | ||
| - | 99 | <title>Low level IPC</title> |
|
| - | 100 | </figure> |
|
| - | 101 | ||
| 84 | <para>The communication between task A, that is connected to task B |
102 | <para>The communication between task A, that is connected to task B |
| 85 | looks as follows: Task A sends a message over it's phone to the target |
103 | looks as follows: Task A sends a message over it's phone to the target |
| 86 | asnwerbox. The message is saved in task B incoming call queue. When task |
104 | asnwerbox. The message is saved in task B incoming call queue. When task |
| 87 | B fetches the message for processing, it is automatically moved into the |
105 | B fetches the message for processing, it is automatically moved into the |
| 88 | dispatched call queue. After the server decides to answer the message, |
106 | dispatched call queue. After the server decides to answer the message, |
| Line 103... | Line 121... | ||
| 103 | immediately closed. The client connection identification (phone id) is |
121 | immediately closed. The client connection identification (phone id) is |
| 104 | not reused, until the client issues closes it's own side of the |
122 | not reused, until the client issues closes it's own side of the |
| 105 | connection ("hangs his phone up").</para> |
123 | connection ("hangs his phone up").</para> |
| 106 | 124 | ||
| 107 | <para>When a task dies (whether voluntarily or by being killed), cleanup |
125 | <para>When a task dies (whether voluntarily or by being killed), cleanup |
| 108 | process is started. </para> |
126 | process is started.</para> |
| 109 | 127 | ||
| 110 | <orderedlist> |
128 | <orderedlist> |
| 111 | <listitem> |
129 | <listitem> |
| 112 | <para>Hangs up all outgoing connections and sends hangup messages to |
130 | <para>Hangs up all outgoing connections and sends hangup messages to |
| 113 | all target answerboxes.</para> |
131 | all target answerboxes.</para> |
| Line 138... | Line 156... | ||
| 138 | 156 | ||
| 139 | <para>On top of this simple protocol the kernel provides special |
157 | <para>On top of this simple protocol the kernel provides special |
| 140 | services closely related to the inter-process communication. A range of |
158 | services closely related to the inter-process communication. A range of |
| 141 | method numbers is allocated and protocol is defined for these functions. |
159 | method numbers is allocated and protocol is defined for these functions. |
| 142 | The messages are interpreted by the kernel layer and appropriate actions |
160 | The messages are interpreted by the kernel layer and appropriate actions |
| 143 | are taken depending on the parameters of message and answer. </para> |
161 | are taken depending on the parameters of message and answer.</para> |
| 144 | 162 | ||
| 145 | <para>The kernel provides the following services:</para> |
163 | <para>The kernel provides the following services:</para> |
| 146 | 164 | ||
| 147 | <itemizedlist> |
165 | <itemizedlist> |
| 148 | <listitem> |
166 | <listitem> |
| Line 167... | Line 185... | ||
| 167 | functionality. To open a new outgoing connection, the client sends a |
185 | functionality. To open a new outgoing connection, the client sends a |
| 168 | <constant>CONNECT_ME_TO</constant> message using any of his phones. If |
186 | <constant>CONNECT_ME_TO</constant> message using any of his phones. If |
| 169 | the recepient of this message answers with an accepting answer, a new |
187 | the recepient of this message answers with an accepting answer, a new |
| 170 | connection is created. In itself, this mechanism would allow only |
188 | connection is created. In itself, this mechanism would allow only |
| 171 | duplicating existing connection. However, if the message is forwarded, |
189 | duplicating existing connection. However, if the message is forwarded, |
| 172 | the new connection is made to the final recipient. </para> |
190 | the new connection is made to the final recipient.</para> |
| 173 | 191 | ||
| 174 | <para>On startup every task is automatically connect to the name service |
192 | <para>On startup every task is automatically connect to the name service |
| 175 | task, which acts as a switchboard and forwards requests for connection |
193 | task, which acts as a switchboard and forwards requests for connection |
| 176 | to specific services. To be able to forward a message it must have a |
194 | to specific services. To be able to forward a message it must have a |
| 177 | phone connected to the service tasks. The task creates this connection |
195 | phone connected to the service tasks. The task creates this connection |
| Line 180... | Line 198... | ||
| 180 | asks name service task to create a callback connection.</para> |
198 | asks name service task to create a callback connection.</para> |
| 181 | 199 | ||
| 182 | <para>Tasks can share their address space areas using IPC messages. The |
200 | <para>Tasks can share their address space areas using IPC messages. The |
| 183 | 2 message types - AS_AREA_SEND and AS_AREA_RECV are used for sending and |
201 | 2 message types - AS_AREA_SEND and AS_AREA_RECV are used for sending and |
| 184 | receiving an address area respectively. The shared area can be accessed |
202 | receiving an address area respectively. The shared area can be accessed |
| 185 | as soon as the message is acknowledged. </para> |
203 | as soon as the message is acknowledged.</para> |
| 186 | </section> |
204 | </section> |
| 187 | </section> |
205 | </section> |
| 188 | 206 | ||
| 189 | <section> |
207 | <section> |
| 190 | <title>Userspace view</title> |
208 | <title>Userspace view</title> |
| Line 208... | Line 226... | ||
| 208 | <emphasis>manager</emphasis> task is found or a new one is created and |
226 | <emphasis>manager</emphasis> task is found or a new one is created and |
| 209 | control is transfered to this manager task. The manager tasks pops |
227 | control is transfered to this manager task. The manager tasks pops |
| 210 | messages from the answerbox and puts them into appropriate queues of |
228 | messages from the answerbox and puts them into appropriate queues of |
| 211 | running tasks. If a task waiting for a message is not running, the |
229 | running tasks. If a task waiting for a message is not running, the |
| 212 | control is transferred to it.</para> |
230 | control is transferred to it.</para> |
| - | 231 | |
|
| - | 232 | <figure float="1"> |
|
| - | 233 | <mediaobject id="ipc2"> |
|
| - | 234 | <imageobject role="pdf"> |
|
| - | 235 | <imagedata fileref="images/ipc2.pdf" format="PDF" /> |
|
| - | 236 | </imageobject> |
|
| - | 237 | ||
| - | 238 | <imageobject role="html"> |
|
| - | 239 | <imagedata fileref="images/ipc2.png" format="PNG" /> |
|
| - | 240 | </imageobject> |
|
| - | 241 | ||
| - | 242 | <imageobject role="fop"> |
|
| - | 243 | <imagedata fileref="images/ipc2.svg" format="SVG" /> |
|
| - | 244 | </imageobject> |
|
| - | 245 | </mediaobject> |
|
| - | 246 | ||
| - | 247 | <title>Single point of entry</title> |
|
| - | 248 | </figure> |
|
| - | 249 | ||
| 213 | 250 | ||
| 214 | <para>Very similar situation arises when a task decides to send a lot of |
251 | <para>Very similar situation arises when a task decides to send a lot of |
| 215 | messages and reaches kernel limit of asynchronous messages. In such |
252 | messages and reaches kernel limit of asynchronous messages. In such |
| 216 | situation 2 remedies are available - the userspace liberary can either |
253 | situation 2 remedies are available - the userspace liberary can either |
| 217 | cache the message locally and resend the message when some answers |
254 | cache the message locally and resend the message when some answers |