On Wed, 8 Jun 2005 18:57:30 -0700, larry@[...].org (Larry Wall) wrote:
>  On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote:
>  : On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
>  : To take a notorious example, you mentioned fork() -- if this event manager
>  : becomes part of Perl6, does that mean we're required to emulate fork()
>  : on win32?
>  
>  Perl 5 manages it, and Perl 6 is expected to emulate Perl 5 when fed
>  Perl 5 code.  It's one of the reasons Parrot is aiming to support an
>  ithreads model in some fashion or other, I expect.  But it's okay if
>  the Pugs interpreter punts on this for now.
>  

If the only reason for using the ithreads model is to allow fork() to be 
emulated using the same mechanism as is used in P5 -- please don't. 

The reason for supporting fork() is (mostly) to allow unix fork() & exec() 
idioms to operate on Win32, but mostly they don't anyway because Win32 doesn't 
support the other components required (signals SIG_CHLD etc.; COW) required to 
allow those idioms run transparently. 

The p5 fork() emulation is barely usable, and has so many caveats that there 
will never be the possibility of transparent portability of programs that use 
fork() to Win32. It will always be necessary to test for platform and make 
special provisions.

And the only instances where the fork emulation does work reasonably well are 
those that are doing fork() & exec(). But thin about that. The emulation, spawns 
a thread, duplicates all the code and all the data from the main thread and 
then...Starts a new process. All that copied code and data is never used because 
all the spawned thread does is sit and wait for the new process to die.

Other uses of fork() like alarm(), also don't work in Win32.

Cygwin manages to perform a proper fork(). The code isn't even that complicated.

>  Larry