catch link(Pid) when trapping exits

Robert Virding <>
Sun Oct 30 14:10:54 CET 2005


You have made a modification which goes against fundamental principle 
(asynchronous message passing and transparency of local remote 
processes) of the process communication mechanism. We, Joe, Mike and I, 
probably never wrote down the priinciples but they were there. Although 
sometimes we aourselves weren't completely consistent either (registered 
processes).

Robert

Raimo Niskanen wrote:

> (Robert Virding) writes:
>
>I have dug into the archives...
>
>This was introduced fairly recently, in R9B, in conjunction
>with the rewrite for more than 255 remote nodes.
>
>We will look into this and decide what to do.
>
>  
>
>>No, no, no it should definitely NOT return error(noproc).
>>
>>The reason is that the whole process communication mechanism,
>>including links, was originally designed to be asynchronous on the
>>sending side. Sending a message is asychronous, ou don't wait in the
>>send to find out if it arrived. Link/1 works the same way. The call
>>does not wait until the link is set up but just sends the request and
>>continues. If the process does not exist the caller is notified by a
>>noproc exit signal from the non-existent process (yes I know but from
>>who else could it receive it?).
>>
>>The important point is that in bothe cases the call is
>>asynchronous. This also means, mostly importantly, that both calls
>>function the same way irrespective of whether the other process is
>>local or remote. This was also an original goal.
>>
>>If this has significantly changed since then then someone has missed
>>the original intentions.
>>
>>Robert
>>
>>
>>Francesco Cesarini (Erlang Training & Consulting) wrote:
>>
>>    
>>
>>>>It is all there, really. Only it was written before exceptions
>>>>were invented as a concept in Erlang, uses the term
>>>>"exit signal" in a confusing way and lies about "does not fail".
>>>>Ok, it is maybe dead wrong, but the intention was right.
>>>>So, what happens is:
>>>>
>>>>link(Pid) -> true           if Pid exists or the caller has
>>>>                            process_flag(trap_exit, true).
>>>>             error(noproc)  otherwise
>>>>
>>>>The enclosing catch evaluates to {'EXIT',{noproc,Stackdump}}
>>>>for error(noproc).            Weird behaviour, in my opinion..
>>>>        
>>>>
>>>Exactly my point. Would it not be better to return error(noproc)
>>>even if trapping exits instead of exit(Pid, Reason)?
>>>
>>>Francesco
>>>-- 
>>>http://www.erlang-consulting.com
>>>
>>>
>>>      
>>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20051030/8e04c05f/attachment.html>


More information about the erlang-questions mailing list