I think we typically underuse the capabilities provided by the operating system in modern programming environments. A lot of thought, design and engineering has gone into providing memory protection, resource management (including releasing resources), caching, debugging, communication abstraction and sandboxing in operating systems. All of these work if your code is divided into processes.
Typical modern component environments, COM+ and J2EE, are thread-oriented. Every request runs in the same process, and even threads normally get recycled. This means that there is no operating system support for providing robustness – everything has to be implemented, and implemented correctly by a combination of application code and the component environment. Even less traditional environments like mod_perl may disregard the benefits to be gained from using processes.
There are of course exceptions. SAP published whitepapers some time ago about their JVM that creates processes for each request. I think typical mainframes still run a standalone process for each form submit/screen update cycle. It’s just that most of us aren’t writing for mainframes.
Process creation is very cheap in modern Unixes, like Linux. You can use chroot and its modern cousing jail to do sandboxing. Memory protection and release of resources on process exit are automatic. Instead of cross-thread function calls, you can use more large-grained IPC primitives (I’d suggest messages and pipes).
You don’t get everything though. The largest thing I miss is pre-defined error information channels (what should cross-process exceptions look like?) and transaction support. Transaction support might be coming with things like Vista’s transactional file system. I guess process-level transaction support is similarly a given on mainframes.
Anybody know if and how COM+ transactions can be integrated with processes?