This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]