From: Dennis Newbold <dennisn@...>
Date: 2002-03-20T06:03:33+09:00
Subject: RE: Development of Windows version of Ruby

Please see my comments below:

On Wed, 20 Mar 2002, Morris, Chris wrote:

> Here's an overview of fork on Windows with Perl. (Google rocks):
> 
> ActiveState announced an agreement with Microsoft to help with Perl on
> Windows that included the addition of fork emulation (June 1999):
> http://www.perl.com/pub/a/1999/06/activestate.html
> 
> 
> ActiveState added fork support for Perl on Windows with ActiveState Perl
> 5.6:
> http://www.activestate.com/Corporate/Communications/Releases/Press971298169.
> html
> 
> 
> The current release is 5.6.1.631. Release notes here:
> http://aspn.activestate.com/ASPN/Reference/Products/ActivePerl/RELEASE.html
> 
> They state: "The fork() emulation has known limitations. See perlfork for a
> detailed summary"
> 
> 
> Here's the perlfork docs:
> http://aspn.activestate.com/ASPN/Products/ActivePerl/lib/Pod/perlfork.html
> 
> They state:
> 
>   WARNING:  As of the 5.6.1 release, the fork() emulation continues to be an
> 
>   experimental feature.  Use in production applications is not recommended. 
>   See the "BUGS" and "CAVEATS AND LIMITATIONS" sections below.
> 
>   Perl provides a fork() keyword that corresponds to the Unix system call of
> 
>   the same name. On most Unix-like platforms where the fork() system call is
> 
>   available, Perl's fork() simply calls it.
> 
>   On some platforms such as Windows where the fork() system call is not 
>   available, Perl can be built to emulate fork() at the interpreter level. 
>   While the emulation is designed to be as compatible as possible with the 
>   real fork() at the level of the Perl program, there are certain important 
>   differences that stem from the fact that all the pseudo child 
>   ``processes'' created this way live in the same real process as far as the
>   operating system is concerned.

    H'mm .. a pseudo child process which lives in the same address space
    as its parent.  Sounds pretty much like a thread to me.  Ruby already
    has threads.  So.. as a bottom line .. if under Windows, we alias
    fork to Thread.new, we can add to Ruby the same level of fork()
    that ActiveState just spent umpteen thousand man-hours putting in.

   And, as a brief summary of a point I alluded to in an earlier post:

   Ruby right now, today, can be used to write a Windows program which
   uses the facilities provided by a Windows OS, and runs fine on Windows.

   It can also be used to write a UNIX program which uses the facilities
   provided by a UNIX OS, and runs fine on UNIX.

   The fact that the two OS's are in some areas incompatible is not
   a reflection on Ruby, and is not a language issue.  If I were to take
   a C program written to run under Windows and using the facilites
   provided by a Windows OS, and try to compile and run it under UNIX,
   there is a good chance (depending on what facilities it was using)
   that it would fail.  This is not a problem with C, and cannot be
   fixed by writing a different C runtime library module.
> 
>   This document provides a general overview of the capabilities and 
>   limitations 
> 
> So ... in 2-3 years, with Microsoft's help, fork support in ActiveState Perl
> for Windows is still sketchy, which greatly amplifies Mark's question:
> 
>   "how important is the lack of a True Fork"
> 
> Chris
>