Changes between Version 2 and Version 3 of IPC
- Timestamp:
- 2009-05-01T12:47:33Z (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
IPC
v2 v3 1 = = IPC for Dummies ==1 = IPC for Dummies = 2 2 3 3 Understanding HelenOS IPC is essential for the development of HelenOS userspace servers and services and, … … 14 14 * [#IpcSkeletonSrv Writing a skeleton server] 15 15 16 == = Introduction to the runtime environment === #IpcIntroRT16 == Introduction to the runtime environment == #IpcIntroRT 17 17 18 18 The HelenOS kernel maintains a hospitable environment for running instances of user programs called ''tasks''. … … 34 34 Fibrils were introduced especially to facilitate more straight forward IPC communication. 35 35 36 == = Basics of IPC communication === #IpcIntroIPC36 == Basics of IPC communication == #IpcIntroIPC 37 37 38 38 Because tasks are isolated from each other, they need to use the kernel's syscall interface for communication with the rest of … … 50 50 of the caller task. 51 51 52 === = Asynchronous framework ====52 === Asynchronous framework === 53 53 54 54 If 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 … … 70 70 The benefit of using the asynchronous framework and fibrils is that the programmer can do without callbacks and state automata and still use asynchronous communication. 71 71 72 === = Capabilities of HelenOS IPC ====72 === Capabilities of HelenOS IPC === 73 73 74 74 The capabilities of HelenOS IPC can be summarized in the following list: … … 87 87 on the data transfer or the memory sharing, respectively. 88 88 89 == = Connecting to another task === #IpcConnect89 == Connecting to another task == #IpcConnect 90 90 91 91 A 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: … … 111 111 The client uses the ''ipc_hangup(int phone)'' interface to close the connection. 112 112 113 == = Passing short IPC messages === #IpcShortMsg113 == Passing short IPC messages == #IpcShortMsg 114 114 115 115 On the lowest level, tasks communicate by making calls to other tasks to which they have an open phone. Each call is a data structure … … 180 180 In this example, ''rid'' is the hash of the received call, ''EOK'' is the return value and ''fd'' is the only return argument. 181 181 182 == = Passing large data via IPC === #IpcDataCopy182 == Passing large data via IPC == #IpcDataCopy 183 183 184 184 Passing 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 … … 193 193 In 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. 194 194 195 === = Sending data ====195 === Sending data === 196 196 When 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. 197 197 … … 240 240 of ''ipc_data_write_finalize()''. If it is non-zero, then there was an error. 241 241 242 === = Accepting data ====242 === Accepting data === 243 243 244 244 When 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 … … 284 284 Note that the return value of ''ipc_data_read_finalize()'' is, maybe unjustly, ignored. 285 285 286 == = Sharing memory via IPC === #IpcShareMem286 == Sharing memory via IPC == #IpcShareMem 287 287 288 288 In 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: … … 294 294 The 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. 295 295 296 === = Sharing address space area out ====296 === Sharing address space area out === 297 297 298 298 When 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.
