| |
Unix Programming - The Elements of Operating-System Style - Cooperating Processes
Cooperating Processes
In the Unix experience, inexpensive process-spawning and easy
inter-process communication (IPC) makes a whole ecology of small
tools, pipes, and
filters possible. We'll explore this ecology in Chapter7; here, we need to point out some
consequences of expensive process-spawning and IPC.
|
The pipe was technically trivial, but profound in its effect.
However, it would not have been trivial without the fundamental
unifying notion of the process as an autonomous unit of computation,
with process control being programmable. As in Multics, a shell was
just another process; process control did not come from God inscribed
in JCL.
|
|
| --
Doug McIlroy
|
|
If an operating system makes spawning new processes expensive
and/or process control is difficult and inflexible, you'll usually see
all of the following consequences:
-
Monster monoliths become a more natural way of programming.
-
Lots of policy has to be expressed within those monoliths. This
encourages C++ and
elaborately layered internal code organization, rather than C and
relatively flat internal hierarchies.
-
When processes can't avoid a need to communicate, they do so
through mechanisms that are either clumsy, inefficient, and insecure
(such as temporary files) or by knowing far too much about each others'
implementations.
-
Multithreading is extensively used for tasks that Unix would
handle with multiple communicating lightweight processes.
-
Learning and using asynchronous I/O is a must.
These are examples of common stylistic traits (even in
applications programming) being driven by a limitation in the OS
environment.
A subtle but important property of pipes and the other classic
Unix IPC methods is that they require communication between programs
to be held down to a level of simplicity that encourages separation of
function. Conversely, the result of having no equivalent of the pipe
is that programs can only be designed to cooperate by building in full
knowledge of each others' internals.
In operating systems without flexible IPC and a strong tradition
of using it, programs communicate by sharing elaborate data
structures. Because the communication problem has to be solved anew
for all programs every time another is added to the set, the
complexity of this solution rises as the square of the number of
cooperating programs. Worse than that, any change in one of the
exposed data structures can induce subtle bugs in an arbitrarily
large number of other programs.
|
Word and Excel and PowerPoint and other Microsoft programs have
intimate — one might say promiscuous — knowledge of each
others' internals. In Unix, one tries to design programs to operate
not specifically with each other, but with programs as yet unthought
of.
|
|
| --
Doug McIlroy
|
|
We'll return to this theme in Chapter7.
To design the perfect anti-Unix, make process-spawning very
expensive, make process control difficult and inflexible, and
leave IPC as an unsupported or half-supported afterthought.
[an error occurred while processing this directive]
|
|
