catch link(Pid) when trapping exits

Rickard Green <>
Sat Oct 29 00:37:43 CEST 2005


No, this behavior was there before R9B, e.g. R5B01:

/usr/local/otp/releases/otp_beam_sunos5_r5b01_patched/bin/erl
Erlang (BEAM) emulator version 4.8.2.8

Eshell V4.8.2.8  (abort with ^G)
1> catch link(pid(0,1234,0)).
{'EXIT',{noproc,{shell,evaluator,[link,[<0.1234.0>]]}}}
2> process_flag(trap_exit,true).
false
3> catch link(pid(0,1234,0)).
true
4> flush().
Shell got {'EXIT',<0.1234.0>,noproc}
ok
5>

It was introduced before OTP. I had a quick look at the R1 code and it 
was present there too.

Regards,
Rickard Green, Erlang/OTP

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




More information about the erlang-questions mailing list