[erlang-questions] EUC 2006 / proposal to enhance message receive

Jay Nelson jay@REDACTED
Tue Nov 14 04:49:01 CET 2006

> It seems to me that your suggestion introduces a new syntax
> without providing new semantics. Using send and selective
> receive it is already possible, semantically, to have
> messages of different priorities.

Yes, you are right, I see that now.  I also see that I didn't handle
priority properly.  It requires nested receives:

receive ->
   {priority_msg, Data1} -> priority(Data1)
   0 ->
       {normal_msg, Data2} -> normal(Data2)
       0 -> none

This pattern applies in the current syntax and in the syntax I proposed.
The problem is you end up polling because you can't wait inside either
of the nested receive clauses.

Control protocols such as pause and resume can also be implemented using
selective receive.

> Instead of adding new syntax can't the implementation be
> improved? That way, the language stays simpler and all
> existing code benefits from the improvement.

You are absolutely right.  The syntax I proposed adds nothing over
selective receive.  There might be an alternate syntax that improves
things, but the behavior of receive under load is the real problem.

The problem is that the default behavior of selective receive
is to check the first message against all clauses, then the second
message, so that it becomes convoluted to nest the cases.

> You're using the phrase "highly reliable" in a way that I am
> not familiar with.

I intended to mean that the implementation inside the VM of the
receive statement is simple -- just a list -- and therefore is easy
to verify.  If it were more complex it would be harder to verify
and debug, therefore more likely to contain obscure errors.

On reflection, the complexity of the receive implementation is less
a concern than the difficulty for users to implement a protocol properly
and efficiently.  Based on the behavioral problems that Pascal pointed
out, a more complex implementation which exhibits better behavior
would be of greatest benefit to the user community.


More information about the erlang-questions mailing list