why concurrency in the first place?

[Raimo Niskanen]

Karel Van Oudheusden wrote:
> P.S.
> I have looked at the "Erlang/OTP R7 - speed test of new inet driver"
> code the last couple of days.  It can be found at:
> http://www.erlang.se/r7_inet_speed/index.shtm.  I am relatively new to
> Erlang.  I must say that this code is not very readable.  I would
> typically choose to use more modules in my code.  And I am very
> astonished about the different (light-weight) processes that are spawned
> every now and then.  Perhaps somebody could explain to me when it is
> interesting (from a specification and implementation point of view) to
> use a seperate process to accomplish something.  I have worked with
> multi-threaded languages previously, but I would have typically chosen
> other kinds of abstractions than the ones made here.  And concluding
> from my above remarks, I now think a specification should contain no
> concurrency at all.

It was a while now, but I feel I have to defend my code a bit. It is a
quick hack to get some figures, not a programming example.

Two or three modules instead of one might not have hurt, on the other
hand all code in one module gives better overview.

The many spawned processes probably comes from the fact that one of the
things we wanted to see were how the scheduling was affected by the new
inet driver. The new driver removed one intermediate process per socket,
and effects of this might show up if there were many processes owning
sockets executing in the emulator.

So, somewhere in the code, an umbrella process is spawned, that
spawn_links a lot of processes each owning a socket. The purpose of this
umbrella process is that it is linked to all testing (socket owning)
processes, and to see if any testing process fails, it is sufficient to
monitor the umbrella process. It dies when any testing process dies,
which kills all other testing processes.

Another reason of complexity is that to get good measurement values, all
tests should be run in a fresh node, so memory fragmentation effects
becomes repeatable, e.g if the memory becomes fragmented, subsequent
tests should not be affected. Therefore the slave:start_link calls, and
the spawn(Node, ...) calls.

Hope this gives some justification to why the code seems more complex
than necessary.

/ Raimo Niskanen, Ericsson UAB, Erlang/OTP development