[erlang-questions] On selective receive (Re: eep: multiple patterns)

[Richard A. O'Keefe]

On 4 Jun 2008, at 6:46 pm, Andreas Hillqvist wrote:

> As I understand it, the discussion in this thread concerns the process
> "default" Message Queue.
>
> What if it would be possible to create Message Queues in addition to
> process "default" Message Queue?
> Where it would be possible to give options such as:
> * limit to the amount message to store
> * what happens when message queue is full
>     * crasch of client/sender and/or server/receiver
>     * notification by message
>     * block sender (I guess this is not a good idea. Because it is
> the opposite to the current semantics of erlangs send.)
> etc...

I'm beginning to sound like Little Johnny One-Note,
but we can already get the effect of multiple message queues by
having helper processes and giving out their PIDs instead.
There's a joke about Haskell programmers:  give them a problem
and they start by saying "I'll just define a new combinator
algebra for that".  The joke about Erlang programmers is "I'll
just spawn another process for that".

This means that we don't find ourselves having to do things like
	{Pid,urgent} ! Msg
or however alternative queues are identified.

Special machinery for some of these options could well make
them more efficient, but LJON again, we don't desperately need
them.  Take limiting the size of the mail box.  What we do is
set up two processes
                     +---------+     +--------------+
         clients --> | counter | --> | real process |
                     +---------+     +--------------+
			\______________/

where the counter process simply forwards all messages to the
real process until it reaches a limit.  Periodically, the
real process sends a message to the counter process saying
that it is willing to receive N more messages.

     counter(Self, Limit) when Limit > 0 ->
         receive
             {Self,Delta} -> counter(Self, Limit+Delta)
           ; Msg          -> Self ! Msg,
                             counter(Self, Limit-1)
         end;
     counter(Self, 0) ->
         receive
             {Self,Delta} -> counter(Self, Delta)
         end.

We can vary the second clause to discard excess messages,
to crash (and via linking, take down Self as well), to
send a special message to Self, or what you please.  We
can use the front end process to filter out bad messages.
If we're willing for the front end process to understand
the protocol, and the protocol includes the sender's pid,
we can track which process sends the most messages and
log or kill the culprit on overflow.  The sky is the limit.
	
After experimentation, some of these approaches may turn
out to be specially valuable, and deserve special support.

The Erlang process system as it exists now is *extremely*
powerful, despite (because of?) its deceptive simplicity.
>

> What is your feedback on user defined Message Queues?

That they are articifially limited processes, and we might
as well use the Real Thing.