What are processes good for?

Chris Pressey <>
Thu Mar 13 16:57:21 CET 2003


On Wed, 12 Mar 2003 21:16:36 -0800
Jay Nelson <> wrote:

> 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.

I have, but I don't see an answer to this question (which is admittedly a
bit rhetorical.)

>  > 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.

Of course it depends on your definition of waste, but I don't think
programmers should ever truly waste resources, even cheap ones, when there
are equally viable alternatives - which is what I would like to explore.

>  > And if not, how do you deal with
>  > the unorthogonality that will almost certainly present?
> 
> I don't understand this question.

Orthogonality = everything is treated the same way

To digress: "everything is a process / object" is a nice mantra, but the
folks at Sun didn't model integers as objects in Java, and I suspect even
Joe would balk at the idea of each record in an ETS table (representing,
say, the Shanghai phone book) getting it's own process.

In other words, it seems that there *can* be too much of a good thing.

Back to orthogonality.  Say we want to hide a textbox.  We know a textbox
has a process, so we say (oversimplified though this is:)

  TextBoxPid ! hide.

Now we want to hide a frame.  Can we say

  FramePid ! hide.

?  Only if each frame has it's own process.

If not - to answer my own question - we can abstract it with a function
call like

  hide(TextBoxId), hide(FrameId).

Not the absolute best approach, but certainly good enough for, erm,
government work.  But still, one has to ask, how far does it go?  How
aware must the programmer be of whether the frame has dynamic behaviour or
not?  Will they be completely oblivious - will they write code to receive
messages that will never be sent?   If so - is it a good thing or a bad
thing?  There are probably arguments both ways.

> [...]
> Processes are useful for:
> 
> 1) Modeling real world concurrent activities.
> 2) Strong encapsulation
> 3) Code reuse / abstraction / adapting interfaces.
> 4) Simulating environmental influences.
> 5) Creating unpredictable, complex behaviour / adaptive behaviour
> 6) Resource management / distribution

These are all useful & interesting points.

However, I submit that #2 and #3 can be done in ways that don't require
processes, and that using processes for them gives you little to no
advantage over doing them without processes.

At the risk of repeating myself - I realize Erlang processes have
infinitesimal overhead, and good Erlang programs are generous with them.

Unfortunately this can decay into the idea that you should use them even
when you don't need them - when you could do it another way which has zero
overhead.

Interfaces - the key idea behind #2 and #3 - are static and mostly boring,
and in Erlang, they can be expressed as part of the module structure. 
(-export())

Although I see how a process can provide an interface as well, I don't see
why it is justifiable to use a process for this purpose *unless* the
interface really has some discernable dynamic property.

In summary - I'm currently leaning towards "most things are processes, but
some aren't, but everything is accessed the same way despite that."

One more point though - I think there is some confusion in the philosophy
about modelling activities with processes.  This may be due to my own
misinterpretation.  Sometimes it's stated as "one process per concurrent
real-world activity", sometimes it's stated as "one process per truly
concurrent activity."  The former is easier to think about, but the real
world is it's own can of ontological beans so to speak, so the latter
interpretation is worth considering too (especially when you think about,
say, Joe's statement about how tcp_server should create two processes per
incoming socket connection - this is much easier to understand in the
context of the latter statement plus an understanding of how
gen_tcp:accept works - arguably not at all part of the "real world".)

-Chris



More information about the erlang-questions mailing list