>
> Perhaps, then, a solution to this fork problem would be to add a Ruby
> method that does fork/exec on Unix and CreateProcess() on Windows?  An
> additional parameter to system() to indicate that the current process
> should not wait for the child to exit before continuing would be
> sufficient.
>
> This is by far the most common use of fork() for me.  I think there may
> be a few more odd cases where I make use of it.
>
> As for fork() and related non-portable calls, perhaps we should consider
> doing as the Python guys have done: place such calls in a namespace of
> its own that indicates that they are non-portable (see
> http://www.python.org/doc/current/lib/unix.html).
>
> Paul
>
This is definitely a good idea, fork is a sophisticated and usefull call in
UNIX,
and as mentioned there is no exact equivalent on win32, however it is often
used
for something very basic which is to do a fork/exec which can be easily done
in
win32, this call should exists separately on ruby in order for those
incompatibility
to go away.
On the other hand there is a very good reason to use fork when you actually
want the
child process to have a copy of data in the parent for example to benefit
from time
consuming initialisation and library loading and to share some memory if
those data
structures are readonly.  This is what is hard to emulate.  But as it is not
the most
common use of fork the previous solution would lessen the problem.
Benoit