vfork instead of fork for fork+exec?
Charles Oliver Nutter
charles.nutter at sun.com
Sat May 16 11:56:23 PDT 2009
Christos Zoulas wrote:
> On BSD vfork() does not share file descriptors, current working
> directory, and signals, and as the following program shows environment
> too so all the items are fine (and it is trivial to write code that
> proves this). If that was not the case (file descriptors were shared
> for example), vfork() would be useless. Even the shell does not
> (because it cannot) use vfork() in every situation, but only when
> it can. I don't know if it is worth the trouble of using vfork()
> in java when it is possible, since fork() is not a very common
> operation in java programs (I think).
The reason it came up for me is that we're trying to make subprocess
launching not suck in JRuby. For example, there's no way with current
process APIs on the JVM to launch a program like vim that needs a real
console to function properly. Using straight-up fork+exec allows that to
Obviously doing this from a Ruby API wrapping a Java API wrapping libffi
introduces some unpredictability into the time between the "fork" call
and the "exec" call, and on Mac it fails to launch spuriously. So I have
been exploring other options.
Anyway, it's not really BSD-specific, so feel free to email me offline
to talk more about it.
More information about the bsd-port-dev