3 ms·
Really surprised at [2] given how robust BEAM is elsewhere. Seems it would be simple for a supervisor to be able to check sizes and kill processes over a certai
by andy_ppp 11y ago
Really surprised at [2] given how robust BEAM is elsewhere. Seems it would be simple for a supervisor to be able to check sizes and kill processes over a certain size. However, actually thinking about it the hot swapping of code and supervision probably works because all the messages/ports/ets/atoms/results can sit there separately while the process can be replaced.
Thanks for the info!
- ramchip 11y agoInterestingly, there's discussion going on right now about adding a similar feature: http://erlang.org/pipermail/erlang-questions/2016-April/088960.html http://erlang.org/pipermail/erlang-questions/2016-April/0889...
- toast0 11y agoGenerally, an erlang supervisor is just waiting for processes to die and react to it; I'm not sure it makes sense to also have it taking an active interest in processes, but you could quickly build something that periodically calls erlang:process_info/2 on all processes, and kills them if they're too big (for whatever value of too big). That would get you protection from one process consuming too much ram, and maybe ports (assuming a process is going to link to its ports, you can examine the links), you could also scan ownership of ets tables. You can't really track which process is using up all the atoms though.