What ever happened to Tandem and NonStop OS 1984

It is "on behalf of the user".

Only scheduling, context setup and interrupts&exceptions really need ring0 priviliges. The rest can be done in a ring1 fashion.

Even if filesystems remain a monolith process it will be a huge win to isolate it. It can then not be damaged e.g. by network code.

There are some subsystems that should be possible to be isolated pretty well. Those are "local" filesystem-swapping-memory mapping; networks anre remote services, processes, pipes and semaphores.

It is a powerful abstraction, and it makes it very easy to code. It is also robust, as it provides a virtual machine for every task.

I beg to counter, it is nice, elegant and robust, but it needs a supplement of more fine-grained control.

This is a way better use of cpu cycles than pushing pretty pictures with animation. It has tangible benefits in terms of fault isolation, robustness and access control.

If you get zombies your code misses some wait4() and kill() calls. It is easy to set up an interrupt and do wait4-kill for child processes. The other alternative is for the child to detach from the parent process and let init do the cleaning.

An FAQ on unix process handling will give you good examples. This is less than a page of code to do right.

Someone has to clean up. With a tiny bit if code you can get init to do it, or the parent process need about 20 lines of code to invoke the right stuff.

I don't see this as problematic at all.

It is not a clean process, it is a clean push level. The old code is still mapped in memory.

I expect the scheduler to handle this all by itself. If the process becomes runnable (i.e. not waiting for some resource) I expect it to be scheduled on some CPU.

Yep, I do. When you do client server interactions you want to bring down the latency from client notification to server wakeup.

If you have clbuttic code you do sumething that end doing a semaphore notify, and as soon as the serving process that waits on that semaphore gets a timeslice it will wake up and serve the request. A score of other stuff can be scheduled in the mean time though. What recycl does is to schedule those notified processes on the remains of your CPU timeslice plus whatever they have on their own.

A typical thing to do is

send(socket, buffer, length); recycl(); recv(socket, ...., buffer, length);

The send() ends doing a notify, but it keeps running. recycl will give the remaining timeslice to the other process directly if it is local, or if it is network code it will schedule the network process.

If the other side is coded the same way it will return the timeslice. Usually recycl() should only be done on clients; or the server should make sure the input queue is empty before it does that.

-- mrr