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

[Onorio Catenacci]

Thanks for taking the time to comment Jesper. Your comments are certainly
illuminating for someone like myself who doesn't know the various details
of Erlang's messaging model as deeply as you do.

On Fri, Jul 15, 2016 at 11:54 AM, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

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



-- 
Onorio Catenacci

http://onor.io
http://www.google.com/+OnorioCatenacci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160715/034cf94a/attachment.htm>