Using vfork() in do_system() instead of fork()

Mike Frysinger vapier@gentoo.org
Tue Jun 23 21:08:00 GMT 2009


On Tuesday 23 June 2009 16:21:29 David Wuertele wrote:
> Mike said:
> > i can almost guarantee you that drepper would tell you to go away,
> > especially because your "problem" only manifests when you've turned off
> > over commit.
>
> I didn't realize there was a recommended overcommit setting with glibc.
> I tried looking for documentation of that, but I can't find it.

you have a MMU, use it

> > vfork() has ugly semantics whose implications are often not terribly
> > clear until it's too late whereas fork() is always straightforward.
>
> I would like to understand more about vfork()'s ugly semantics.  If there
> is a ramification that could bite me if I use vfork() instead of fork(), I
> need to make sure I understand it before taking the risk.

a vfork()-ed child shares memory with the parent.  so your function should 
generally read:
if (vfork() == 0)
	_exit(exec(....));

if you setup the args ahead of time you shouldnt have a problem

> I think that both of these ramifications are non-issues in do_system(),
> because the child immediately calls execl().  So what other ramifications
> are there?

the problem with using it in common code is that if you want to make any 
changes in the future, you need to do a full rereview of your changes to make 
sure you dont screw something up.  internal interfaces have to be fully aware 
of locks, cancellation end points, memory leakage, etc...  throwing vfork() 
semantics onto the stack isnt to be done lightly.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-help/attachments/20090623/879780ce/attachment.sig>


More information about the Libc-help mailing list