http://qs321.pair.com?node_id=989803


in reply to Re^2: pipe fork win32
in thread pipe fork win32

I re-booted my machine and I ran your code and it did work!

The sleep(1) in the client is what I tried before and it did not work. I think that there are some flaky things having to do with Win XP. After a re-boot this worked. I am completely flabbergasted why it did not work before. 

#/usr/bin/perl -w
 use strict;

 my $pid = fork();
 die "fork() failed: $!" unless defined $pid;
 if ($pid) {
     print "I am the child pid =$pid...\n";
     
     while ( sleep 1 ) {
        print  "I am still the child  ". localtime()."\n";
     }    
 }
 else {
    print "I am the parent\n";
    
    while (sleep(2)) {
        print "I am still the parent ". localtime(), "\n";
    }
 }
__END__
C:\TEMP>perl browser.pl
I am the parent
I am the child pid =-4808...
I am still the child  Sun Aug 26 01:10:36 2012
I am still the parent Sun Aug 26 01:10:37 2012
I am still the child  Sun Aug 26 01:10:37 2012
I am still the child  Sun Aug 26 01:10:38 2012
I am still the parent Sun Aug 26 01:10:39 2012
I am still the child  Sun Aug 26 01:10:39 2012
I am still the child  Sun Aug 26 01:10:40 2012
I am still the parent Sun Aug 26 01:10:41 2012
I am still the child  Sun Aug 26 01:10:41 2012
I am still the child  Sun Aug 26 01:10:42 2012
Terminating on signal SIGINT(2)

[download]

Replies are listed 'Best First'.
Re^4: pipe fork win32
by bojinlund (Monsignor) on Aug 26, 2012 at 12:54 UTC

    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?

[reply]
      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]
      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]
      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]
Re^4: pipe fork win32
by BrowserUk (Patriarch) on Aug 26, 2012 at 14:11 UTC
    I am completely flabbergasted why it did not work before.

    Yeah! Me too.

    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]
      I previously had been working on recovering data from a damaged SD card. I managed to get 1,500+ files off of this thing. But Windows was not "happy" and I had to re-boot many, many times during this process. I also do not know how, but there do appear to be some kinds of errors that can mess Windows XP up in weird ways. I do not know why.
[reply]

In Section Seekers of Perl Wisdom