start_link and death of parent

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

start_link and death of parent

Fredrik Linder-2
Hello OTP Folks

I get this very strange behaviour from otp-r9c-0 built on redhat-8 or redhat-9 (not 100% sure which).

Is this a known problem in r9c-0, and if so is it corrected in r9c-1?

(traffic)265> whereis(d).
undefined
(traffic)266> l(d).
{module,d}
(traffic)267> P=spawn(fun()->io:format("result: ~w~n", [catch d:start_link()]) end).
<1308.2281.0>
result: {ok,<1308.2282.0>}
(traffic)268> erlang:is_process_alive(P).
false
(traffic)269> whereis(d).
<1308.2282.0>
(traffic)270> erlang:is_process_alive(whereis(d)).
true
(traffic)271> exit(whereis(d),kill).
true
(traffic)272> whereis(d).
undefined
(traffic)273>

Shouldn't <1308.2282.0> die when <1308.2281.0> dies.

The 'd' module is just the emacs skeleton for gen_server in of r9c-0 with -define(SERVER, ?MODULE).

/Fredrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d.erl
Type: application/octet-stream
Size: 4689 bytes
Desc: d.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20040617/14384023/attachment.obj>

Reply | Threaded
Open this post in threaded view
|

start_link and death of parent

Matthias Lang-2
Fredrik Linder writes:

 > Is this a known problem in r9c-0, and if so is it corrected in r9c-1?

 > Shouldn't <1308.2282.0> die when <1308.2281.0> dies.

No, it should not die.

By default, a linked process only exits if it receive an abnormal EXIT
signal. Your 'fun' is exiting normally, thus the linked gen_server
does not and should not exit.

Or have I completely misunderstood your problem?

(BTW: there's a very nice, concise Erlang reference up at
 
   http://www.erlang.org/doc/r9c/pdf/reference_manual-5.3.pdf

Great work, whoever wrote it.)

Matthias