New implementation of Process classes

In R3.0, class Process has two derived classes, StackProc and HeapProc, which serve as the base classes for client processes. StackProc and HeapProc differ in where a process's stack is located when the process is running: a StackProc has its stack located on the real stack in the stack segment, while a HeapProc has its stack in the free storage area in the data segment. A context switch of a StackProc involves copying the active part of the current process's stack into a save area, then copying the saved stack of the new process onto the real stack. A context switch of a HeapProc involves simply resetting the processor's stack pointer and frame pointer registers to point to the new stack, so a StackProc context switch is much slower than a HeapProc context switch. However, using HeapProcs tends to break debuggers, which usually can't cope with the bizarre stack location, so programs using them are difficult to debug. Also, the stack area for a HeapProc must be specified when it is constructed, and must be large enough to hold the largest stack that can occur anytime during execution. In contrast, the stack save area for a StackProc grows in size if necessary and must only be large enough to hold the largest stack in use when the process is suspended. Thus, the tradeoff is debuggability and reduced memory requirement vs. speed.

Fiddling with the stack area and machine registers is something you can't do directly from C++, so processes are inherently non-portable. The R3.0 implementation of the Process classes attempts to use the C library routines setjmp(), longjmp(), and alloca() to do context switching. While this works on many machines, you may need to write your own versions of these routines for machines on which it doesn't. See the section on PORTING THE PROCESS CLASSES for instructions.