vfork instead of fork for fork+exec?

[Christos Zoulas]

On May 16,  2:02pm, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: vfork instead of fork for fork+exec?

| On Sat, May 16, 2009 at 11:56, Charles Oliver Nutter
| <charles.nutter at sun.com> wrote:
| > 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. =A0Even 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=
| 
| 
| Are you aware of
| http://download.java.net/jdk7/docs/api/java/lang/ProcessBuilder.html#inheri=
| tIO()
| 
| In JDK6, you can do something non-portable like
| 
| Runtime.exec("/bin/bash", "-c",
| "exec /usr/bin/vim < /proc/$PPID/0 > /proc/$PPID/1 2>/proc/$PPID/2")

You mean /proc/$PPID/fd/<n>, but I guess it is prolly better in this
case to just use /dev/tty, both from a portability perspective and also
because you are going to fail gracefully if your process does not have
a tty.

christos