Re^4: pipe fork win32

Hej Marshall,

I had similar experiences a year ago with the emulation of fork in Windows (Windows 7 Home Premium with Service Pack 1).

Running the tests of Test::TCP (version 1.11 and 1.12) on Windows resulted often in a blocking Perl interpreter. Sometimes the system reached at state, that it must be restarted.

I started trying to isolate the problem and this is so far I came: https://rt.cpan.org/Public/Bug/Display.html?id=66016#txn-910155.

My experiences/conclusion using perlfork - Perl's fork() emulation in Windows, are:

There is stochastic involved. Two identical calls (expected to give the same result) can give different results. What I understand is the problem in the implementation of the Windows API and not in the Perl implementation.
In some cases the processes running the Perl interpreter are blocking (coming in an unwanted state).
Sometimes the problem is not solved by restarting the Perl interpreter. Is there some missing initializations in the Perl interpreter?
In some rare situations the total system (not just the process running the Perl interpreter) is affected, and must be restarted. Sometimes it even must be restated using power down/up. The isolation between processes and the operating system in Windows has some weakness?

The questions which worries me are:

Is it advisable to use the Perl's fork() emulation in Windows in “production” code?
Is it enough to run the test of Perl modules just once or how many times are they needed to be run?

Comment on Re^4: pipe fork win32

Replies are listed 'Best First'.
Re^5: pipe fork win32 by bulk88 (Priest) on Aug 26, 2012 at 13:57 UTC
Fork in general is fine, although most/all CPAN modules will leak resources with fork unless they specifically say they are psuedo fork safe (have a CLONE method or use mg_dup magic). Doing a kill on a child absolutely isn't safe and never will be completely safe see ( https://rt.perl.org/rt3/Ticket/Display.html?id=88840 ). Previously doing a kill on the child the moment the parent starts the child (why would you do that in production code?) would hang the parent interp later in the parent interp's execution. I am not doing a kill anywhere. I need to, and have the child exiting voluntarily.	[reply]
Re^5: pipe fork win32 by BrowserUk (Patriarch) on Aug 26, 2012 at 14:40 UTC
Is it advisable to use the Perl's fork() emulation in Windows in “production” code? Personally, I'd say that you should not use Perl's Win32 fork emulation at all. This not necessarily because of bugs in that implementation -- though I have no doubts they exist -- but because that emulation is not complete enough to allow *nix programming paradigms to be ported to windows without changes its actual behavior isn't well-enough (at all?) documented to allow for a set of rules to be written down about what will and won't work. As is, the fork emulation creates expectations of portability that are simply not achievable. Better I think to simple say "do not use". With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply]
Re^5: pipe fork win32 by Marshall (Canon) on Aug 30, 2012 at 08:15 UTC
Is it advisable to use the Perl's fork() emulation in Windows in “production” code? Windows just doesn't do "fork" very well. Threads are the way to go with Windows, but that model is more complex. BrowserUK knows a lot about how to do this on Windows. I would say that emulate behavior X on Y, often doesn't work out that well.	[reply]