Proclets - light-weight processes in JNode

The idea of a 'proclet' is to provide a light-weight equivalent of UNIX processes in JNode without the potential overheads of isolates.

The 'process' is one of the key abstractions in a UNIX/Linux operating system. A process consists of an address space with one ore more execution threads, and has an array of file decriptors, a set of environment variables, a current directory, a real and effective user and a few other things. In addition, a process can be reliably controlled from the outside; i.e. it can be killed, suspended and debugged, and can have its scheduling properties modified.

We can (and should) provide the same functionality in JNode using infrastructure built ion top of isolates. However:

1. Isolates are likely to be rather heavy-weight; e.g. expensive to start and memory hungry.
2. We don't always need all of the functionality of UNIX-style processes; e.g. we can often dispense with separate address spaces, and external control if the code is "well-behaved".
3. Isolates are not working in JNode yet, and there is no concrete plan to complete them.

As an alternative, a 'proclet' would be a light-weight equivalent of a process that runs in the same isolate as the object (e.g. shell) that launched it. A JNode command launched as a proclet would have its own current directory, properties, environment variables and standard input/output/error streams. The command would be able to use classic Java mechanisms (e.g. File.getAbsolutePath(), System.getProperty("user.dir"), System.in, System.setIn()) while being insulated from the effects of other proclets.

Lsantha suggested the name 'proclet' for this concept, and I really like it. However, I suspect that it is not new to the Java world. (Once upon a time, there was a system called "Echidna" ....)

Implementing proclets will entail making changes to (at least) the implementation of System to make it aware of proclet contexts:

• The System.in,out,err streams need to be proxy objects that dispatch to context-specific streams.
• The System.setIn,setOut,SetErr methods need to update the context specific streams.
• System.getProperties() and friends need to read and update context specific Properties objects.
• Etcetera.

Proclet-specific state can be implemented using ThreadLocal or by subtyping ThreadGroup. I'm using the latter approach at the moment, and it seems to be working ok. I haven't considered the API visibility and security issues yet ...