Wish list (for somebody making a new OS)

From time to time it comes to me a neat feature for a new operating system. Before I forget about the last one, here it is: ..drum roll, please..

Lightweight Processes

What? I hear you say. Let me explain.

In your run of the mill OS, there are processes and they are good and they suffice most of the time, but once every so often a process becomes so popular, so successful that everyone wants to be part of it. Examples abound: the web browser, the e-mail client, the text editor and so on. In fact, it seems that every user-mode process harbors deep in it a secret desire to be some day, famous like that. If not itself maybe its descendants.

Anyhow, the problem is that the successful process, becomes a container of plug-ins, each plugin effectively being a peer of every other plugin attached to the process an a peer of the process itself, the result is that all the nice guarantees of an OS process go out the window, and in fact the process itself has become a poorly written, non-preemptive operational system. In other words a bad DOS clone.

I am sure it is similar to the experience of Shakira's mom when she visits her daughter house. Who are all these people hanging around, smoking and drinking? do you even know all of them? see that guy? he just spit in the carpet!! who drank all the milk and left the empty bottle in the fridge? this is chaos. I am leaving.

So, in my terminology (because I am sure lightweight process has been taken) a lightweight process has two key properties:

1- It depends on one (and only one) regular process, but
2- it is still a process: it has its own virtual memory space and security profile

The first point, being dependant on a regular process means:
a- A regular process can spawn a child lightweight process, but a lightweight process cannot spawn by itself other regular or lightweight processes
b- When the regular process terminates, all associated lightweight child processes will be terminated (with no recourse) by the operating system.
c- Lightweight processes have access only to a subset of the operating system API that regular processes have. For the rest, a child process will communicate with the parent process and the parent process can fulfill (or not) the request.

To the second point, a lightweight process can be forcefully terminated by the OS without having necessarily to terminate the parent process, and more importantly the parent process can terminate forcefully the child process without risking memory (or other) corruption.

Some people can point that you can do this kind of things today with the infrastructure provided by rich OS such as Windows. For example, if a plug-in model in windows is similar to COM, then a lightweight process is similar to an out-of-process COM server. But if you thing about it you'll see it is not the case.

There is more to the subject. For example I think it will be appropiate to have a special memory model between the parent and the child process, one that comes to me right now is that the parent process can write to the child process memory, and the child process can read the parent process memory, except that the parent can designate pages that are not readable and the child can do the same and specify pages that are not writeable. There would be no option for the child to write to the parent memory or for the parent to read memory. There is also a case to be made for some special model for threads and some specially efficient IPC model, where doing an IPC between parent/children does not cause a full blown context switch but cause more like a continuation [1] kind of deal.


[1] "Using Continuations to Implement Thread Management and Communication in Operating Systems" by Draves, Bershad, Rashid and Dean. 1991 Carnegie Mellon University.