| |||||||||||||
Fighting fork bombsFighting fork bombsPosted Apr 3, 2011 19:06 UTC (Sun) by giraffedata (subscriber, #1954)In reply to: Fighting fork bombs by vonbrand Parent article: Fighting fork bombs
Keeping processes around just because some descendent is still running is a waste of resources. Seems like a pretty good return on investment for me. Maybe 50 cents worth of memory (system-wide) to be able to avoid system failures due to runaway resource usage and always be able to know where processes came from. It's about the same tradeoff as keeping a process around just because its parent hasn't yet looked at its termination status, which Unix has always done. A process that no longer has to execute shouldn't use an appreciable amount of resource.
(Log in to post comments)
Fighting fork bombs Posted Apr 7, 2011 9:24 UTC (Thu) by renox (subscriber, #23785) [Link]
Currently when the parent exits its memory is totally freed, you're suggestion keeping the whole process until its children exits which can be expensive, maybe a middleground could be more useful ie keep only the 'identity' of the parent process and free the rest.
Fighting fork bombs Posted Apr 7, 2011 15:16 UTC (Thu) by giraffedata (subscriber, #1954) [Link] you're [suggesting] keeping the whole process until its children exits which can be expensive, maybe a middleground could be more useful ie keep only the 'identity' of the parent process and free the rest. I don't think "whole process" implies the program memory and I agree - if I were implementing this, I would have exit() free all the resources the process holds that aren't needed after the program is done running, as Linux does for zombie processes today. But like existing zombies, I would probably keep the whole task control block for simplicity.
|
|||||||||||||