posix_spawn's usage of fork versus vfork

Mike Axiak mike@axiak.net
Fri Oct 8 00:15:00 GMT 2010


2010/10/7 Ángel González <keisial@gmail.com>:
> How is it failing? There's a small penalty on marking all the process pages
> as copy-on-write, then unmarking, but I don't see what would make a fork()
> to fail but a vfork() to succeed there (considering).

The fork() is returning with ENOMEM, and vfork succeeds. I don't have
too much experience with the kernel, but it seems that it's just
running out of virtual memory space, not actual memory.

> Maybe you are running with overcommit disabled?
> Also note, that bug 5049299 is marked as fixed.

If you're referring to '/proc/sys/vm/overcommit_memory', then I am
using the default 0 (use linux default heuristics). This is a good
catch -- I'll play with it and report the results.

As for 5049299, the java bug reporting is a little misleading here --
it is marked as "6 - Fix Understood", which as far as I know means "we
have a general plan, but no fix in place". I could be wrong, though.

> If I had to work around it, I would probably create a zygote process at
> the beginning and then route all new process requests through it.

So basically you would use a pipe to send a "fork and exec" command to
the zygote process? Interesting method, and would certainly perform
better than my option (1) outlined above. For reference, I have a
solution on github [1] to use vfork via posix_spawn. The strategy is
to use a helper proc:

    ./binrunner stdinfd stdoutfd stderrfd chdir program arg1 arg2 ....

So if I ran:

   ./binrunner 0 2 1 ls -l

In this case, my binrunner would run as a glorified shell ">&2 2>&1".

Anyway, thanks for the help.

Mike


1: http://github.com/axiak/java_posix_spawn



More information about the Libc-help mailing list