sön 2011-10-09 klockan 16:34 +1300 skrev Amos Jeffries: > We still have and occasionally hit the same old OOM ceiling on fork() > with multi-GB RAM caches, but its a noticeably less common complaint now.
And the workaround is as before to make sure to have plenty of swap space available, preventing OOM, or alternatively enable memory usage overcommit. Note: The swap only needs to exist to temporarily enable the virtual memory to be reserved, it's not actually swapped to by the fork+exec. Note 2: Linux by default enables a quite significant memory usage overcommit ratio, hiding most of this fork() virtual memory requirement madness from the user. Using vfork() has too many pitfalls to be considered imho. It's a broken by design interface. Actually fork+exec is also a broken interface but at least somewhat workable (but we don't do it correctly in error cases) A better alternative is to use posix_spawn() where available. Maybe with fallback on fork+exec if there is any systems we need to support which lacks posix_spawn() support today. This path also means dropping the helper communication channel validation, just as using vfork does. Basically the viable choices boils down to a) Keep existing fork+exec code, with it's benefits (validation, error reporting etc) and drawbacks (virtual memory explosions). b) Drop helper channel validation and switch to using posix_spawn() solving the virtual memory explosions. Regards Henrik
