<br><br><div class="gmail_quote">2009/3/9 Valentin Micic <span dir="ltr"><<a href="mailto:v@pharos-avantgard.com">v@pharos-avantgard.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'd like to add one more concern: considering operational characteristics of<br>
Erlang VM, I think that adding support for join patterns at such a low level<br>
(i.e. receive...end construct) may cause performance degradation.<br>
It may be safer (at least at this point) to achieve this as a part of<br>
post-receive processing, by having some form of, say, correlation context,<br>
as hinted by Richard. Bad (or IMO good) news is that this would not be part<br>
of the language syntax.<br>
<font color="#888888"></font></blockquote><div><br>I tried to give it a go in implementing the joins directly in VM, but it would take me too much time to get through all the magic that goes in erts.<br>Instead, I added primitives that allow me to manipulate the mailbox directly and do all the logic of joins directly in Erlang.<br>
I believe that you won't get performance degradation for standard receive constructs (i.e. joins with single pattern), or at least the drop should be marginal.<br>However, at the end of the day, the users should have more freedom to do synchronization on messages (solutions should be more elegant).<br>
<br>The implementation in VM would not be ready to go straight to the standard VM, it is more of a proof-of-concept that such that thing is useful and allows me to experiment with joins.<br>It might be even better to leave the plain old receive construct, and add join construct that works similarly, but is more powerful.<br>
</div></div><br>