vfork instead of fork for fork+exec?

[Charles Oliver Nutter]

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

http://blog.headius.com/2009/05/fork-and-exec-on-jvm-jruby-to-rescue.html

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.

- Charlie