<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 July 2015 at 07:22, Éric Pailleau <span dir="ltr"><<a href="mailto:eric.pailleau@wanadoo.fr" target="_blank">eric.pailleau@wanadoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
Le 10 juil. 2015 01:18, Fred Hebert <<a href="mailto:mononcqc@ferd.ca">mononcqc@ferd.ca</a>> a écrit :<br>
><br>
> On 07/10, Éric Pailleau wrote:<br>
> >A = catch Pid |  {somemessage, somevalue }.<br>
> >This would probably need a timeout. On other hand,  ! + receive may wait forever. | could do the same.<br>
><br>
> A = [catch Pid | {somemessage, somevalue}].<br>
><br>
> Is A equal to:<br>
><br>
> a) [Pid | {somemessage, somevalue}] (improper list)<br>
> b) [Result] (the received message)<br>
><br>
</span>Yes, you are right. But I do not request that pipe must be the operator. If !! Is better, I do not care. The need is more important than the syntax itself.<br>
<span class=""><br>
<br>
> It also ignores that two processes may have more than two communications<br>
> going on at the same time, and that without a selective receive, it's<br>
> not obvious that anything would match properly.<br>
</span>I m not sure to understand there. We are talking about synchronous message. When using gen_server:call you do not receive answer to another request,  but yours.<br></blockquote><div><br></div><div>It does that because the gen_server:call wraps your message with a tagged tuple containing for the sender pid and a unique ref. It then goes into a receive waiting for a message containing that unique ref. The receiving end understands this when it sends it reply it includes the unique ref so the sender will receive the right message.<br><br></div><div>The reason for explicitly doing all this work is that all the receiving process sees is exactly the message that was sent, no more no less. There is no implicit information included at all. This means that if you were to add a synchronous message then you would have to either add a new message handling, not just in the message itself but maybe in receive as well. Or you could say that one of these messages will have a specific format which you can receive and you must reply with a specific format.<br><br></div><div>Another problem is that synchronous message passing is much more complex and you need to define/handle many more things in the system than with async messages. For example how to handle you not getting a reply, do you use timeouts, or check if the other process has died, or a combination of both, etc? So you either end up with a set of special case operators/calls or a call with lots of options.<br><br></div><div>And how should it work with distribution where today it is the same.<br><br></div><div>No, I didn't like Joe's suggestion. :-)<br><br></div><div>Robert<br> <br></div></div></div></div>