[erlang-questions] Pipe Operator in Erlang?

[PAILLEAU Eric]

Hi Robert,

thanks for your thoughts.
mine inline below.

>
>
> 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.
>
> 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.
Yes I know this. It is probably far more complicated than async messages.
But even if Erlang power is in async messages, and if possible async 
messaging must be used, there is always 10% of case where sync message 
is necessary. Erlang would be a real killer language if sync messaging 
was as async level.

I encounter the problem when adding the process state view in observer.
Apart : BTW , State format is not standardized, well I mean not common 
to all kind of processes . /Apart.
Some , well, most, processes do not even handle system messages .
And as far I know there is no way to know it in advance, or to "ask" it 
to the process. The lonely way (?) is to send a system message, and wait 
an answer (or not) with a timeout. Result, you have to wait a timeout in 
most case.
processes might, MHO, always answer to system messages, at least to
tell that system messages cannot be handled, because no sys callback are 
available. On contrary, if the behavior allow it, the answer to a
special system message may indicate if sending a sync message is possible.
This way, it would be possible to know if a process can handle a sync 
request, obviously a cache must probably be used in order not to ask 
each time if a process can handle a sync message.

>
> 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.

Either the process do not handle sync message (see my upper comment), 
and an error or exception must be raised immediately, or the process 
can, and the default sys module 5000 ms timeout apply to the !! (or 
whatever) operator.

If a different timeout is needed, a VM flag can be created.
And for any other case, old style  ! + receive + after or plain 
gen_server:call for gen_servers are still possible.

>
> And how should it work with distribution where today it is the same.
Version of Erlang VM must be verified in order to know if process
on a node can answer to system messages. If no, the sync call must 
return immediately an error or an exception.
>
> No, I didn't like Joe's suggestion. :-)
Yes I understood this :>) ...

Regards