What are processes good for?
Thu Mar 13 06:16:36 CET 2003
Chris Pressey wrote:
> But what about controls without state, or barely any state,
> I wonder? Like pushbuttons and frames and labels. Do
> they still get processes?
See discussion below. Frames and labels are generally
static adornments. They could be changed by external
function calls, or could be active themselves, but today
they are generally just static state. Push buttons are input
devices and need to be asynchronous stream signallers
to other processes; they need to be always alive and able
to send messages instantly. Their appearance on the screen is
less relevant as in the case of frames and labels.
> If so, why, if it is wasteful enough to warrant not doing it?
Programmers should always waste resources in order of
their availability. Amongst processes, memory, CPU
cycles, communication bandwidth, etc. each situation may
vary, but waste the cheapest and most abundant resource
if it makes the code clearer, faster or more correct. In erlang
processes are abundant, and if you need more CPU "wasting"
them across nodes can increase performance if communication
overhead is low.
> And if not, how do you deal with
> the unorthogonality that will almost certainly present?
I don't understand this question.
Thoughts on Processes
Joe, et al, say that there should be one process for each
real world concurrent activity (or something along those lines).
Which is equivalent to the OO answer that there should be
one Object for each real world object being modeled.
While this is a good guideline, it assumes that the software
is modeling real-world processes and activities. There are
other reasons for using processes (once you are no longer
a beginning programmer in erlang). Here are a few I thought
of. I would be interested in any additions that others think of.
Processes are useful for:
1) Modeling real world concurrent activities.
- Self-explanatory for "liveness" purposes, but also
in the realm of simulating multi-agent systems
where each process is an independent agent.
- OO programming would fall here.
2) Strong encapsulation
- This is an engineering design decision to hide
state, and provide a black-box communication
interface to prevent unpredictability inside the model.
- Finite state machine programming.
- Or OO programming could fall here if you are not
doing simulations or are working with abstract objects.
3) Code reuse / abstraction / adapting interfaces.
- If strong encapsulation is used, two processes may
only be able to talk to one another if they are aware
of the interface design. An adaptor process can be
added to allow reuse of the two without modification
(within the limitations of semantic equivalence).
- If a complicated feature is not yet implemented, a
simple substitute can be dummied up in a process
and replaced later (although functions work as well,
build, execution and management may be simplified
by a separate process).
- Streams can be transformed by successive process
filtering to interface two existing bodies of code, or to
simplify the algorithms by eliminating exception
4) Simulating environmental influences.
- In test situations a stream of sample data is
useful in exercising a system, or where access to the
real environment is prohibitive (e.g., the device is not
yet built, the sensors need to be in outer space,
catastrophic physical world failures, etc.)
- This could be viewed as #1 but I think it warrants
5) Creating unpredictable, complex behaviour / adaptive behaviour
- Dynamic feedback of multiple very simple processes
can be used to create complex behaviour. Think of
a series of differential equations.
- The ease of process creation and death allows for an
approach to adaptive systems based on the collection
of active processes changing in response to external
6) Resource management / distribution
- Relocation of connected resources may require the
code to run on a different processor. Processes are
more easily managed and dynamically distributed.
- When a resource has initialization and finalization
needs, a process that traps EXITs can simplify the
- Code replacement may be easier if the functionality is
subdivided to account for stateful and stateless pieces;
processes allow for simpler replacement policies.
- Non-stop operation requires replication, failover and
redundancy as well as partial or whole retry semantics.
- When a resource is in short supply on a single node,
(e.g., power, CPU speed, memory, attached storage)
distributing the processing to several nodes may be a
necessary architectural consideration.
- Providing several peripherals with a common interface
or network accessibility requires separate processes on
Any other ideas?
More information about the erlang-questions