• View
• Edit
• History
• Print

MessagePassing

Author: Chani

See also: StandardIPCMessages

Cy/VOS is a hybrid-kernel system, neither fully microkernel nor monolithic. The design is meant to handle both kernelspace and userspace drivers.

Of course, this requires an efficient method for communicating between several applications. To this end, Cy/VOS is developed with the goal of message passing.

Low-level implementation

The message passing structure is that of shared memory synchronous message passing. Two tasks communicate via the kernel-level application dispatch system (the Dispatcher) in order to establish a channel. During the establishment of the channel, a certain amount of memory is allocated, shared between the two applications.

Since IPC is synchronous, there are no race conditions involved. Application A fills a message into the shared buffer, and invokes the kernel to switch to task B. The kernel then modifies application A's task structure to indicate that its timeslice belongs to task B. Then, whenever application A would be granted a timeslice, task B gets the timeslice instead. This enforces strict priority inheritance, even when tasks are being called from several different task levels. Task B is then responsible for picking up messages from the message queue. The message queue is a kernel data structure holding a priority-and-time-sorted list of channel ID's. Task B picks the first available channel ID, then reads the data out of the shared buffer. It may then place a reply in the shared memory buffer, and invoke the kernel to return control of application A.

Priority is strictly maintained throughout the entire sequence through use of both timeslice donation and priority-aware message queues.

Application-level perspective

Messages under Cy/VOS can be divided roughly into two categories: protocol and custom. "Protocol" refers to the fact that every server and manager on the system -- both core and optional -- will have a protocol of defined commands for using that server. Custom messages are those whose structure is not defined by the Cy/VOS developers and which are used to send new commands to custom server software and for software to talk amongst itself.

Protocol messages are further divided into two types: required and optional. Required messages, also known as layer 0 or the required layer, are those which client applications must send or must be able to handle correctly. The majority of defined messages fit into layer 1, or optional: clients are not required to send them at any time to use the service and are not required to recognise and handle them upon reception. These boundaries are not as firm as they could be and some commands are interrelated such that if the program understands one, it must then understand another. Layers 0 and 1 as a concept are open for review.

"Layer 2" refers to custom commands.

Telcontar asks: Will the Cy/VOS SDK come with a standard IPC marshalling service akin to AppleEvents or are programs intended to be left to take care of their own message structure? (see the linked page for notes)

I also wonder, will Cy/VOS present a service functionally akin to UNIX stream sockets and pipes? For things like command line pipes and CGI where you merely want to open a pure data stream from one process to another.

Hmm... I also wonder about asynchronous and notification mode. If the remote process does not need to reply (or you simply don't care, it's not your responsiblity what it does with the message), you may not want to block your own process and lose the CPU in order to the transmit a message, you might want to send it off and retain the CPU, and have any reply arrive in the message queue later.

Effectively, not a redesign of the system but merely different interfaces on top of it, including the regular sendMsg_synch(), sendAndDontCareWhatItDoesWithIt(), and openStream()...

Also: what sort of flow control will be implemented to prevent a process from flooding the dispatcher with messages and overloading it (either maliciously, or by way of buggy code)?

--- Chani responds: IPC is largely defined in an application-defined way, although the dispatcher does have certain standardized messages.

Streams, sockets, and pipes are all wrappers around the basic message-passing system.

Asynchronous notifications are generally a bad idea. Flow control is unnecessary because notifications are purely synchronous and thus at the discretion of the server. The message queue will sort out the messages as they arrive, and the server will pick them out of the queue. Timeslice donation ensures that there is no way of flooding the dispatcher, since the dispatcher will execute within the timeslice of the offending process, at the priority of the highest priority task waiting in the queue.

While it is entirely possible for a task to use multiple threads in order to allow something to continue executing in parallel with the service it is calling, in general, strict timeslice donation obviates the need: when the process sends a message to a service, the service immediately wakes up with the complete remaining timeslice of the calling process, services the request, and then, assuming time remains in the timeslice, returns back to the calling process, which continues with the remainder of its own timeslice.