According to the Solaris man-pages (5.5.1) it suspends the calling thread
until the child either calls exec*() or exits.
Although the Solaris man pages may be right in this regard, they are
out of date in another. The Solaris implementation actually uses
threads and will share signal disposition and other state.
Aliasing fork() to vfork() is beginning to sound more and more
promising...
It isn't going to work until you recompile all of your applications
using fork to have the compiler treat fork() just like setjmp()
for register allocation purposes. I guess nobody has considered this
issue yet. The problem is that right now, for fork(), the compiler
assumes it can leave local variables in callee saved registers around
the fork() call, for functions like vfork() and setjmp() such objects
must be on the stack since the child can and will change them if they
were just left in registers.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/