This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: posix_spawn's usage of fork versus vfork
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