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

[David Wuertele <dave+libc-help at wuertele dot com>]

>> > 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

Sure, that would be any sane programmer's preference.  But on this point
I am at the whim of other users of the system.  I wonder if my constraint is
really that unusual?

As long as the Glibc authors/maintainers don't specify a supported or
recommended value for the overcommit setting, I think it is reasonable
to expect system() to work even if my process has already malloced
more than half of available ram, don't you?

> 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.

Naturally.  And probably the glibc developers have higher priorities
to deal with
than this, which is essentially a scalability issue.  So I won't hold
my breath.  But
I might send a few emails :-)

Dave