A process is a part of an application (a program), which 1. is running possibly in parallel to other parts in a preemptive way, is a thread, 2. communicates with other parts, processes via character streams (pipes), 3. is memory isolated from the other processes (memory protection, region, address space) and 4. cleans up all its used resources when exiting.
Definitely a unix process is a process as defined right now. On a real UNIX (like Linux on an i386) the preemptiveness and the memory protection is supported by the CPU.
A good choice for defining, which parts will become the processes of an application, is the commands as described in the next section.
There is said, that is is one strategic property, that a command is
callable as a C-function in addition to being a process (which in C
means, that there is a starting function int main(). This is
important to be able to use commands in critical places without
restarting a process too often.
But it is equal important to have the commands available as processes.
The char stream interface (pipe) guarantees a simple interface. An
interface, which can be communicated from within different programming
environment. For example a structured and complex list structure in a
lisp program can never be read or written by a
bash script. So even, when the C-function version of
commands communicate with c struct's, these
struct's are just mapped simple char stream data areas. The
structs are used to accelerate parsing, because it uses a fixed width
format.
(The format is <delimiter><fixedWidth><delimiter><fixedWidth><delimiter><fixedWidth><delimiter>... so that the delimiters are always on the same columns and missing data is padded by blank. The delimiter is inserted for readability by humans and for other programs, which can easily delimiter but not fixed width (like Microsoft's excel).
The really extremely important thing about processes is: they cannot disturb each other and the don't leak. And so if one of the commands or processes (the part of your application) is written not too well, it does not harm the application as a whole. If subcommand leaks memory, after the ending of this command, all memory is back again (of course, if the operating system does not leak).
The prototype of this kind of architecture is the bash: bash is a frame for a system administration application, or a program development application (depending of the subcommands used). Suppose bash itself does not leak and not crash. Then a leaking gcc, find or vi does not disturb the overall application. After find exits, everything evil is gone.
Using the atexit() possibility, other resources (like database
connectors) can equally secure be made water-proved.
So bash's ls -l | grep regExp is the template, the basic architecture, the core of each application.
In a graphical environment the command line bash would be replaced by a graphical frame, and instead of typing the command names, the user would click in menus, but this would invoke real processes, which are equally flexible plugged into the graphical frame like commands can be integrated into bash.
Of course there should not be the creation of millions of processes in a short time. But for example one process for each OK-button and each menu item is certainly OK.
This extreme importance of processes makes it worth to support them syntactically. Again the bash is a perfect example of how simple the syntax of command and pipe could be.
The siliconBrain frame should provide some C-macros or functions to support bash, gawk or perl style forking.