Do you envisage your queues as separate things or always bound to original process?<br><br>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.<br>
<br>And at that stage we had not yet begun to think about distribution.<br><br>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.<br>
<br>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?<br>
<br>Robert<br><br><div class="gmail_quote">2008/6/4 Andreas Hillqvist <<a href="mailto:andreas.hillqvist@gmail.com">andreas.hillqvist@gmail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thank you for your answer.<br>
<br>
For sending I was thinking that it would be possible to use the Queue<br>
Identifyer (somthing similar to a PID):<br>
      Queue ! Message<br>
<br>
And that Queue are only linked to process.<br>
<br>
<br>
One possebility with Multiple Queues is that it would be possible to<br>
Prioritize messages more efficiently:<br>
 * If there is a message in Queue read messsage, else repeat for next Queue.<br>
 * If there is no message in any Queue, wait for a message from any Queue.<br>
<br>
It might be nice to have one Queue for system messages and such.<br>
<br>
<br>
I do not know if the Multiple Queues is the right path.<br>
It would be possible to build some of the functionality with helper<br>
process for Queue.<br>
<br>
And that could be part of the framework you mentioned and let the<br>
future decide if the Multiple Queues semantics will catch on.<br>
<br>
It might then be omre efficently be implemented in the Erlang Runtime.<br>
<br>
<br>
Kind Regards<br>
Andreas Hillqvist<br></blockquote></div><br>