[erlang-questions] -pidname( <atom> ) Was: Why we need a -module() attribute?
Fri Mar 4 12:59:23 CET 2016
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
> 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
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 . ;>)
More information about the erlang-questions