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.