Are you ready for the Clicker generation ?

Programs and Process

Main Concepts: Process, Job, Thread...

This section will covers Clicker'processes organisation and communication.

Process

 Note that, in Clicker, processes are quite heavy objects, that deal with a whole "private" address space, personnal files and other memory objecs, etc.
Processes may be local (on your machine) or remote (on another machine). Clicker Network Server will manage "remote control" for each remote process you deal with.
A process is mainly a running program so, the main system call you'll get to create a process is to run a program

Thread

 In one process, you may have several thread, each one running its own instruction flow, with a personnal stack and register bank.
Because they are part of the same process, threads are supposed to work cooperatively rather than concurently. This means thread are not protected from each other by the system unless the program is in *SUSPICIOUS* mode.
Clicker Scheduler deals only with thread. A process-scheduler may be added if you - for example - want to swap back a whole program you're not using from a while. (called a long-term scheduler).

Job

 Jobs are "logic unit of work", such as requests to a server, or some computations. Jobs are not immediately supported by kernel but require a library to run. A job is consisting of a instruction list and a state. This State is more general that a processor state: it's made with each local var the job uses.
Jobs should be a migrable stuff, which means you might be able to define a job on one machine and execute it on another.
Jobs will probably be interpreted rather than binaries, for security and communication purpose.

Scheduling

Clicker does not fix a specific process-scheduler. Each operating mode may define its own scheduling policy. By the by, the *MAIN* mode will define a generic scheduler whose goal would be to improve programs reactivity to events (from users or other programs)
Moreover, Clicker should provide some event server that should allow programs to register functions to be called when an event occur. Some of those event might be defined by another user-level program, so that you could have lighting-fast response to other program's signals.
Wether you're at system or user level, the event-response would be called directly (i.e. for disk irq, mouse, etc...) or through interrupting the target thread and then placing it on a "priviledged" queue.

Communication

The main communication scheme, in Clicker, will be mailboxes. Each process is given a mailbox, which allows him to get message from other process or to prepare message he'll send to other process.
This scheme can work as well on the same local machine (where you just need to use shared memory for mailboxing between processes) or with remote processes (the remote control will then send messages through the network to it's target or hold the message coming from remote process)
In addition to mailboxes, semaphores would be used to synchronize trheads of a same process. For convinience, mailboxes will probably also use a few of their shared memory to provide process-level semaphore, even it's not necessary.
I also think we'll need some name-server to identify special classes of programs. This should be necessary to find some servers in L.A.N. In addition, a user-level name server might be used to allows user-level programs (games, etc.) to register themself and thus be known by pairs (other games clients) without interfering with more "serious" servers (ftp, fonts, x, files...)