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

[Paul Mineiro]

We saw big message queues for the logger process in yaws.  We upped the
priority of the logger process and they went away.

That was basically an N -> 1 problem.

-- p

On Fri, 6 Jun 2008, Robert Virding wrote:

> Do you envisage your queues as separate things or always bound to original
> process?
>
> Way back in the dark misty beginnings of Erlang we had a wonderful concept
> called the pipe to which messages were sent and received. Pipes has their
> own lives and were not bound to an original process. With these pipes you
> could do wonderful things like redirect them and join them together
> (muff_pipe/2). However, they were also by far the most complex and difficult
> part of the early Erlang interpreter so we were very glad to see them go.
> Joe wrote a bit about them in his HOPL paper.
>
> And at that stage we had not yet begun to think about distribution.
>
> Anyway the goal of this rather long discourse is "no, I don't think this is
> a good idea". It is extremely easy to create really weird interactions with
> this I think.
>
> I have a serious question which I ask out of ignorance. I know that really
> long message queues are possible in the existing language, it is easy to
> write a program to show this, but do they occur in real applications? Or is
> this theoretical worry? And if they do occur are they something which is
> property of the problem which can't easily be avoided or are they the result
> of some error in the logic or coding which shows up in message queue length?
>
> Robert
>
> 2008/6/4 Andreas Hillqvist <andreas.hillqvist@REDACTED>:
>
> > Thank you for your answer.
> >
> > For sending I was thinking that it would be possible to use the Queue
> > Identifyer (somthing similar to a PID):
> >      Queue ! Message
> >
> > And that Queue are only linked to process.
> >
> >
> > One possebility with Multiple Queues is that it would be possible to
> > Prioritize messages more efficiently:
> >  * If there is a message in Queue read messsage, else repeat for next
> > Queue.
> >  * If there is no message in any Queue, wait for a message from any Queue.
> >
> > It might be nice to have one Queue for system messages and such.
> >
> >
> > I do not know if the Multiple Queues is the right path.
> > It would be possible to build some of the functionality with helper
> > process for Queue.
> >
> > And that could be part of the framework you mentioned and let the
> > future decide if the Multiple Queues semantics will catch on.
> >
> > It might then be omre efficently be implemented in the Erlang Runtime.
> >
> >
> > Kind Regards
> > Andreas Hillqvist
> >
>

In an artificial world, only extremists live naturally.

        -- Paul Graham