[erlang-questions] Reactors, Channels and Event Streams for Composable Distributed Programming

[Jesper Louis Andersen]

On Fri, Jul 15, 2016 at 2:19 AM, Onorio Catenacci <Catenacci@REDACTED>
wrote:

> It's a free PDF but you have to register on the site.  Given the audience
> here I thought it might present some interest to some of you.


It is an interesting paper, which touches of many of the possible
generalizations that are possible in Erlang's messaging model.

* In Erlang, a receive clause is static and receive patterns are not first
class variables. In other words, you cannot *combine* different receive
clauses which, as the paper mentions, hurt modularity at this level. On the
other hand, it is easier to optimize receive clauses if they are static
since they will always be module-local.

* The paper curiously omits Concurrent ML as related work. CML subsumes
most of the paper and was written back in 1993. In CML there are two
abstractions: one, you can combine "receives" by combining the selectors of
those receives. Second, the result of a receive are events, which can
*also* be combined. It adds another abstraction layer. But the cost of this
abstraction is that it will not work in a distributed setting. It is
local-only.

* The paper makes no attempt at handling multi-party communication with
cycles. Assume a client C, a proxy P and a worker W:

    C messages P
    P forwards the message to W
    W responds to C

This is obviously faster than factoring every message back through P. And
it is a quite common pattern in Erlang systems. These are also protocol
patterns which needs to be handled well by protocol typing.

* The paper has no mention of error handling in the situation of a combined
reactor. We better have a way to identify what part of the reactor failed,
and is it possible to let other parts of the combination continue even if
other parts failed?

That said, it is *always* nice to have new ways of thinking about
concurrency. And the authors definitely has a point with the need for a way
to "combine" actors algebraically. It would remove lots of boiler-plate
code since the systems can often be "layered". I think the reason we don't
have the need is that *most* processes can be written as gen-servers, and
their receive patterns are pretty straightforward. They want to read every
kind of message and forward it to the callback module, unless the process
is part of a call. But this is fairly easy to handle with static receive
clauses. I'm not saying the idea is bad, but if you can demonstrate a
problem in Erlang which would be helped a lot by the construction, then you
have a far better case. If, OTOH, every construction has a direct nice
alternative in Erlang, then you may want to conclude the abstraction wasn't
so useful after all.



-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160715/8cfd3e99/attachment.htm>