[erlang-questions] On selective receive (Re: eep: multiple patterns)
Fri Jun 6 23:23:39 CEST 2008
Do you envisage your queues as separate things or always bound to original
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?
2008/6/4 Andreas Hillqvist <>:
> 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
> * 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions