|The Möbius Operating System: Inter-Process Communication|
This document describes the forms of inter-process communication available to Möbius applications programmers, and provides an overview of the functionality and implementation of each.
The Möbius provides three main forms of IPC:
Ports in The Möbius are most similar to sockets in other operating systems. Ports are separated into server and client ports.
Client ports, once connected to a server port, can be read from and written to like any other file. They are created by creating or opening a file in the ports directory (by default, /System/Ports). It is the responsibility of the client task to keep track of client port handles, as with any other file object. Server ports can neither be read from nor written to. Server ports start out as unconnected client ports; they gain their server status when the server task calls PortListen. Server ports are kept track of by the port file system, and their names are stored in a global list. A server port handle become signalled each time a client connects to it. A typical client-server interaction using ports is as follows.
Ports support asynchronous I/O, as do most types of file object in The Möbius. Reads will block until there are as many bytes in the port's buffer as required by the read; write will block if the write would go past the end of the buffer. Client-to-server connections are also asynchronous, even though they are made using the synchronous FsOpen. Assuming that the parameters are correct (i.e. the server port exists), FsOpen will signal the server port and return immediately without error. However, it could be some time before the server task can service the request and call PortAccept. Therefore, the first read or write request on a client port will block until the port is fully connected. If the connection failed, the first read or write request will fail because of that (and not because of some I/O error). If a guaranteed connect is required then it is possible to call FsOpen followed by a zero-byte FsRead to verify the connection. If either calls fail then the connection has failed; otherwise, the client is free to send and receive data through the port.
Although the required framework is present in the kernel, shared memory is not currently made available to user applications.
Messages are the main method of inter-process and inter-thread communication in the Möbius GUI. Messages are fixed-length structures containing a 32-bit code, a target window handle and three general-purpose 32-bit parameters.
Messages are received in the message loops of GUI threads, and are generated either in the kernel window manager, in response to external events such as user input or window invalidation, or by other threads or processes. Each GUI thread has a kernel message queue, which expands to contain any messages sent to a window owned by the thread but not handled. Messages are removed from the queue when handled.
Normally the GUI programmer would not need to deal with messages directly: system-defined messages are handled by Window::HandleMessage and directed to the appropriate virtual member function. However, messages can make a handy form of inter-thread or inter-process notification: Window::PostMessage can be used to post messages to a window in the same process, and xxx - some_function_i_havent_written_yet can post messages between processes. To handle a custom message, or redefine the behaviour of an existing one, override Window::HandleMessage.
xxx - should be possible to post messages to threads as well.