2008/6/2 Mats Cronqvist <<a href="mailto:mats.cronqvist@gmail.com">mats.cronqvist@gmail.com</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Ulf Wiger wrote:<br>
> I would really like to discourage people from avoiding<br>
> selective receive because it's "expensive". It can be<br>
> expensive on very large message queues, but this is<br>
> a pretty rare error condition, and fairly easily observable.<br>
><br>
<br>
</div>  i think the "issue" of how the emu deals with huge in-queues is pretty<br>
uninteresting.<br>
  in my personal experience, every single time this has come up the real<br>
problem has turned out to be lack of proper flow control (typically<br>
using {active,true} sockets). having 100k messages in an in-queue is not<br>
a realistic use case.<br>
  the fact that this is not, afaik, particularly well documented is of<br>
course a problem.<br>
</blockquote></div><br>This is true - but if one has no prior experience of this situation, it is hard to understand why a system is behaving sluggishly. What will be nice is having an option, as Ulf suggested earlier, to have bounded message queues (kill the process if the message queue length exceeds a certain value). That way, flow control problems will be more readily visible to users. In real life situations, when a process gets into this state, the only way to fix it is to kill that process as it will probably never catch up. This has been discussed before: <a href="http://www.erlang.org/pipermail/erlang-questions/2006-January/018364.html">http://www.erlang.org/pipermail/erlang-questions/2006-January/018364.html</a><br>
<br>It also fits in well with the "Let it crash" philosophy.<br><br>cheers<br>Chandru<br><br>