[erlang-questions] Message Receive Semantics (was eep: MultiplePatterns)

[Jay Nelson]

Valentin wrote:

 > Consider a following scenario: for every five "high" priority  
messages
 > processed, I wanted to handle three "normal" and one "low" priority
 > message(*). To implement this with a selective receive is  
relatively easy
 > and concise, even for a novice programmer. To do without it, may be
 > considerably more difficult and messy.


I think priority is one of the harder cases to get right, actually.   
The beginner
will end up blocked waiting for the 5th high priority message when only
4 are on the queue, or will end up delaying high priority messages while
they scan for low priority ones.

So here is the concrete challenge:

1) Send a message to a linked process:
     a) {request, Msg}
2) The other process should generate 20 or so messages randomly
     and then quit
3) Always handle messages in the following order:
     a) 5 messages of {reply, high, Msg}
     b) 3 messages of {reply, normal, Msg}
     c) 1 message of {reply, low, Msg}
     d) 'EXIT' message

Of course, there may not be 5 remaining high messages or 3 remaining
normal messages so you need to deal with these end cases.  In doing so,
make sure you don't just end up polling every 100 milliseconds.  I've
simplified the problem by only having one process that can generate
replies, so that the selective receive doesn't become even more
complicated.

I challenge any beginner or intermediate erlang programmer to write
and post the code for both processes and  a description of your results.
All the advanced erlang people can help point out the issues that will
have to be addressed when you change the initial code approach.

At least, that is my bet.  Valentin may be right.  Let's see some code!
In another post, I'll give an alternative problem that is easier and
shows the usefulness of selective receive.

In general, I would argue that erlang's approach to message is geared
towards handling multiple conversations or sessions on a single channel,
and that handling priorities is a pathological case for the simple  
message
queue approach that erlang uses.  It is far easier to implement  
priorities
by unloading the whole queue into a process which implements a priority
queue and then doling out messages according to your own priority logic.

jay