The "too small to fail" memory-allocation rule

Posted Dec 24, 2014 10:18 UTC (Wed) by ibukanov (subscriber, #3942)
In reply to: The "too small to fail" memory-allocation rule by roc
Parent article: The "too small to fail" memory-allocation rule

> One great feature of the fork()/exec() model is that you can set up the child's environment by running code in the child before exec

To customize the child before exec one does not need full fork, vfork is enough and does not require overcommit.

The "too small to fail" memory-allocation rule

Posted Dec 24, 2014 11:34 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (3 responses)

Only in Linux. The POSIX description is "you can store the return value from vfork(), then you have to call _exit or exec".

The "too small to fail" memory-allocation rule

Posted Dec 24, 2014 12:31 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (1 responses)

Linux semantic of vfork is one of the most usable as it blocks only the thread in parent that calls it. Thus one can get rather safe and efficient alternative to fork/exec by creating a new thread, calling vfork from it, preparing the child and calling the exec. Compare that with, say, FreeBSD or Solaris that, according to the manual pages, suspends the whole parent process during the vfork call.

The "too small to fail" memory-allocation rule

Posted Dec 30, 2014 0:04 UTC (Tue) by klossner (subscriber, #30046) [Link]

By "create a new thread" do you mean call pthread_create? That just ends up in do_fork(), which creates a new process with which to call vfork(), which ends up in do_fork() to create another new process. Safe, okay, but not really efficient.

The "too small to fail" memory-allocation rule

Posted Dec 24, 2014 14:27 UTC (Wed) by justincormack (subscriber, #70439) [Link]

Most versions allow you to do more than this though, not just the Linux one. Makes it all rather non portable though.