A rough analogue (although not to be taken too literally) is that a process is to C++CSP what a function is to C, and what a class is to Java. A process is a subclass of CSProcess or ThreadCSProcess, that implements the pure-virtual run() method to provide the code for the process.
Processes can then be run in different ways. More information on this can be found on the Running Processes page.
Stack Sizes:
If you wish, you can provide a stack size to the constructor of CSProcess or ThreadCSProcess. The exact use of this value is dependent on the underlying Operating System; however it is guaranteed to be a minimum available stack size.
The default minimum stack size is one megabyte. This is the default maximum stack size on Windows, and should be a safe maximum stack size. However, most users will not be interested in increasing this size, but rather in decreasing it. If this memory was actually all allocated (which on some systems it could be), this would require one megabyte of stack size per process. On a machine with one gigabye of memory and two gigabyte of swap space, this would give a maximum of less than 3,000 processes.
A temptation might be to reduce it as low as possible. On systems where the minimum could drop so low, allocating a four kilobyte stack could allow 256 times as many processes - over 700,000 processes on the machine described above. However, this stack size would be very dangerous on most systems. Not only do you have to allow for your own stack usage, but any system calls or calls to library functions might use up a large amount of stack space, especially if the call might be recursive.
Unfortunately there is no magic formula or easy estimation to work out what a safe small stack size is. If you do use many processes, do not specify a stack size and stick with one megabyte. If you do need extra performance - 64 kilobytes usually seems to work fine for me for processes making system and library calls, and 8 kilobytes seems to be workable for very simple processes (such as Id). To help keep your stack usage low in applications where you need to shrink the stack as much as possible, do not allocate large data structures on the stack (something that is not good practice anyway). You'll notice that all the common processes such as Id put their data in class variables rather than on the stack. Allocating classes on the heap with new/delete is the other obvious method of avoiding over-use of the stack.
Do not become over-zealous in avoiding the stack - this practice is only necessary when the memory allocation of the object is many kilobytes. Usually, the underlying storage of collection classes (such as vector, list, map) is on the heap, so such objects can safely be placed on the stack. The only likely use of a lot of memory would be large arrays, or objects containing large arrays.
C++CSP v1.x Compatibility:
The main change to processes since C++CSP v1.x is the new availablity of kernel threading. This is also dealt with in detail in the page on Running Processes. ThreadCSProcess did not exist in v1.x and instead all processes inherited from CSProcess. These processes should almost all remain that way, unless you now want to change them to always running in their own thread, in which case inherit from ThreadCSProcess instead. If you simply want to run the process in a new thread in a particular instance, leave it untouched and read up on running it as a new thread on the Running Processes page.
The other change is that in C++CSP v1.x, CSProcess contained methods for sleeping, yielding and forking. Forking is now taken care of in ScopedForking, whereas sleeping and yielding use the global methods CPPCSP_Yield(), CPPCSP_SleepUntil() and CPPCSP_SleepFor() (named to avoid conflict or confusion with similar OS functions). Previously, using the CSProcess methods from a function called by a process was very difficult, so these global functions make the user's life easier, and de-clutter the CSProcess (and now ThreadCSProcess) class.
Classes | |
| class | csp::CSProcess |
| The base class for processes, that allows processes to be run in a new thead or the same thread. More... | |
| class | csp::ThreadCSProcess |
| A direct sub-class of ThreadCSProcess (except of course CSProcess) is a process that will always be started in a new thread. More... | |
1.4.7