Uncertain death

[Dominic Williams]

Oh yes, I realize that. I'm not bothered at all by the delay,
although I wouldn't mind a neater way of "waiting" for its
death than timer:sleep/1.

What bothers me is the contradictory information provided by
is_process_alive(Pid) and processes(). That seems like a bug
to me.

Dominic.


> When you send an exit signal to a process,
> it is scheduled in order to receive it.
> This goes for 'kill' messages as well, even
> though you'd think that they could be
> killed right away by the runtime system.
>
> /Uffe
>
>> -----Original Message-----
>> From: owner-erlang-questions@REDACTED
>> [mailto:owner-erlang-questions@REDACTED] On Behalf Of
>> Dominic Williams
>> Sent: den 17 november 2005 23:32
>> To: 'erlang-questions@REDACTED'
>> Subject: Uncertain death
>>
>> Hello,
>>
>> The following program seems to me to indicate that when a
>> processes gets killed, there is, for a brief moment,
>> contradictory information about its state. Specifically, the
>> information returned by processes() seems to lag behind that
>> given by is_process_alive().
>>
>>
>> %%% death.erl
>>
>> -module (death).
>> -export ([run/0, server/0]).
>>
>> run() ->
>>      Pid = spawn (?MODULE, server, []),
>>      exit (Pid, kill),
>>      report (Pid),
>>      timer:sleep(1000),
>>      report (Pid).
>>
>> report (Pid) ->
>>      io:fwrite("~p alive: ~p; member of processes(): ~p~n",
>>                [Pid, is_process_alive (Pid),
>>                 lists:member(Pid, processes())]).
>>
>> server () ->
>>      receive
>>          hello ->
>>              server();
>>          stop ->
>>              bye
>>      end.
>>
>> %%% end death.erl
>>
>> 1> c("/Users/dodo/tmp/death", [{outdir, "/Users/dodo/tmp/"}]).
>> {ok,death}
>> 2> death:run().
>> <0.35.0> alive: false; member of processes(): true <0.35.0>
>> alive: false; member of processes(): false ok
>>
>> Same result under MacOS/R9C and WinXP/R10B
>>
>> Regards,
>>
>> Dominic Williams
>> http://www.dominicwilliams.net
>>
>> ----
>>
>