One of the base criterion for resource access is belonging to a given process group. So its necessary that resource providers can maintain such groups: building them from a set of process identifiers, adding/removing process, delegating ownership, etc.
Moreover, some process id will be reserved for special uses:
This kind of communications is for threads that belong to the same process. As they lie in the same address space, it's not necessary to enter kernel mode to let them communicate (they have trivial way for exchanging datas and sharing files :)
The underlying idea is that two thread of the same process will cooperate with each other, and so they needn't protection again each other. The program itself will have to manage the access to shared resources
Exchanging message is the main communication way between process under Clicker. Each process receive a mailbox segment where it will receive messages from other process.
Usually, the process will create a thread that will read and dispatch (or respond) these messages. Reading messages should be a priviledged operation (compared to background computations) in the scheduler so that we give the precedence to interactions between programs (and especially between user interface management and programs) on heavy computations (like compilations, simulations ...)
An alias mechanism should allow a process to share a region of its address space with other process. Once the alias is created, the process can define a set of process that will be allowed to read the region and another set with read and write access.
The alias identifier is then sent (i.e. through a message ;) to another process which can map the alias in its own address space.
The system should enable global (usable by any set of process) semaphores. These semaphores will be changed at kernel level and will require aliases to appear in the different process' spaces.
Note that it could be useful to group those shared resources (semaphores and memory segments) on a single page and have access properties for the group of resources
The key idea of events is to program interrupts of a thread by a function. When installing this interrupt, we bind the function to an event identifier that can be used by other process to raise the event.
Events are asynchronous, which means the sending process needn't to suspend itself and may continue to run, while the receiver thread will have to wait for dispatching by the scheduler.
However, threads that received an event are usually priviledged against "normal" threads. So a "normal" that sends an event can make it nearly synchronous by suspending itself after sending
Each event is given a class which is used as a priority level between events. When a class n event is active, lower-classed events are blocked and queued so that they can be processed when the higher-classed event will finish.