Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Version 2 and Version 3 of IPC


Ignore:
Timestamp:
2009-05-01T12:47:33Z (10 years ago)
Author:
Jiri Svoboda
Comment:

Make use of L1 headings.

Legend:

Unmodified
Added
Removed
Modified
  • IPC

    v2 v3  
    1 == IPC for Dummies ==
     1= IPC for Dummies =
    22
    33Understanding HelenOS IPC is essential for the development of HelenOS userspace servers and services and,
     
    1414 * [#IpcSkeletonSrv Writing a skeleton server]
    1515
    16 === Introduction to the runtime environment === #IpcIntroRT
     16== Introduction to the runtime environment == #IpcIntroRT
    1717
    1818The HelenOS kernel maintains a hospitable environment for running instances of user programs called ''tasks''.
     
    3434Fibrils were introduced especially to facilitate more straight forward IPC communication.
    3535
    36 === Basics of IPC communication === #IpcIntroIPC
     36== Basics of IPC communication == #IpcIntroIPC
    3737
    3838Because tasks are isolated from each other, they need to use the kernel's syscall interface for communication with the rest of
     
    5050of the caller task.
    5151
    52 ==== Asynchronous framework ====
     52=== Asynchronous framework ===
    5353
    5454If a task is multithreaded or even if it has only one thread but several fibrils, the idea of connection is jeopardized. How can the task tell which
     
    7070The benefit of using the asynchronous framework and fibrils is that the programmer can do without callbacks and state automata and still use asynchronous communication.
    7171
    72 ==== Capabilities of HelenOS IPC ====
     72=== Capabilities of HelenOS IPC ===
    7373
    7474The capabilities of HelenOS IPC can be summarized in the following list:
     
    8787on the data transfer or the memory sharing, respectively.
    8888
    89 === Connecting to another task === #IpcConnect
     89== Connecting to another task == #IpcConnect
    9090
    9191A HelenOS task can only communicate with another task to which it has an open phone. When created, each task has one open phone to start with. This initial phone is always connected to the naming service. The naming service is a system task at which other services register and which can connect clients to other registered services. The following snippet demonstrates how a task asks the naming service to connect it to the VFS server:
     
    111111The client uses the ''ipc_hangup(int phone)'' interface to close the connection.
    112112
    113 === Passing short IPC messages === #IpcShortMsg
     113== Passing short IPC messages == #IpcShortMsg
    114114
    115115On the lowest level, tasks communicate by making calls to other tasks to which they have an open phone. Each call is a data structure
     
    180180In this example, ''rid'' is the hash of the received call, ''EOK'' is the return value and ''fd'' is the only return argument.
    181181
    182 === Passing large data via IPC === #IpcDataCopy
     182== Passing large data via IPC == #IpcDataCopy
    183183
    184184Passing five words of payload in a request and five words of payload in an answer is not very suitable for larger data transfers. Instead, the application can use these
     
    193193In theory, the programmer can use the low-level short IPC messages to implement all three phases himself. However, this is can be tedious and error prone and therefore the standard library offers convenience wrappers for each phase instead.
    194194
    195 ==== Sending data ====
     195=== Sending data ===
    196196When sending data, the client is the sender and the server is the recipient. The following snippet illustrates the initial phase on the example of the libc ''open()'' call which transfers the path name to the VFS server. The initial phase is also the only step needed on the sender's side.
    197197
     
    240240of ''ipc_data_write_finalize()''. If it is non-zero, then there was an error.
    241241
    242 ==== Accepting data ====
     242=== Accepting data ===
    243243
    244244When accepting data, the client is the recipient and the server is the sender. The situation is similar to the previous one, the only difference is that the client
     
    284284Note that the return value of ''ipc_data_read_finalize()'' is, maybe unjustly, ignored.
    285285
    286 === Sharing memory via IPC  === #IpcShareMem
     286== Sharing memory via IPC  == #IpcShareMem
    287287
    288288In HelenOS, tasks can share memory only via IPC as the kernel does not provide dedicated system calls for memory sharing. Instead, the tasks negotiate much like in the case of [#IpcDataCopy passing large data]. The negotiation has three phases and is very similar to the previous case:
     
    294294The semantics of the client and server also remains the same. Note that the direction of sharing is significant as well as it is significant during data copying.
    295295
    296 ==== Sharing address space area out ====
     296=== Sharing address space area out ===
    297297
    298298When sharing an address space area to other tasks, the client is the sender and the server is the recipient. The client offers one of its address space areas to the server for sharing.