[erlang-questions] -pidname( <atom> ) Was: Why we need a -module() attribute?

[PAILLEAU Eric]

Le 04/03/2016 06:14, Richard A. O'Keefe a écrit :
> Second, even pure Erlang has a Window to Hell.
>      exit(Pid, Reason) can kill *any* process that is not trapping exits.
>      group_leader(Leader, Pid) can set the group leader of any process,
>         willing or unwilling, knowing or unknowing
>      list_to_pid(String) lets you forge pids
>      erlang:ports() returns a list of all the ports on the local node
>      erlang:processes() returns a list of all the processes on the local
> node
>      erlang:resume_process(Pid) and
>      erlang:suspend_process(Pid[, Options]) let you break things in a way
>         that even Java's designers couldn't stomach any longer.
> and those are just the ones I know about.  The result is that you can NEVER
> assume, for example, that a process that has no reason to suspend *isn't*
> permanently suspended.  In the Erlang shell, type
>  > [erlang:suspend_process(P) || P <- erlang:processes(), P /= self()].
> and watch your shell never come back...

not to mention : io:write(self(), 'something'). that never return.
Good syntax is io:write(group_leader(), 'something').
Being in a shell and self() is not the pid that can handle io is very 
strange for new comers (even if it is understandable by reading the code 
and documentation).
I proposed a fix that replace self() by group leader, but was rejected.

My feeling : a soft realtime software that have functions that never 
return (at least a timeout) is really weird and in some way do not 
follow the 'let it crash' philosophy .
But... C'est la vie.

 > I not saying "don't HAVE a window to hell", what I'm saying
 > is that there needs to be a fence around it.

spawn_priv/x could be a brick in this goal, but as far security is not a 
subject in Erlang VM, we must live listening AC/DC's "Hell ain't a bad 
place to be" , doing orgies with succubi . ;>)