Re: pipe fork win32

[Marshall]

in reply to pipe fork win32

This Windows fork() is a weird thing, because it uses threads to emulate what a Unix fork() would do.

I tried to write a simple scenario, but ran into problems with sleep(). My 'work-around' in the child process is not efficient, but it appears to work on Win XP, Perl 5.10.1.

I'd like to know a bit more about the application... The parent can send various flavors of "kill" to the child (you know its process id - and "kill" is basically a one bit message) and the child can have a signal handler to intercept this and figure out what to do. I don't see the need for any kind of "read" operation between the parent and the child, but maybe I don't understand what you need.

BrowserUk knows way more about communication between Windows threads than I do, but it doesn't sound like that is required? Setting up an IP connection between the client and the parent is possible, but I'm not sure of the need for that.

This is not a "server" it just forks a single child. More complex scenarios are possible.

#/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 (1)
    {
      `ping 127.0.0.1 -n 5 > nul`; 
              # sleep() won't work on Windows in multiple threads
              # the pid is a negative number and this a 
              # thread (fork emulation)
              # there is Windows "weirdness" with sleep
              # here I started a command that will "wait"
              # for awhile before returning. 
              # this is inefficent, but appears to work
              
       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 client_server.pl
I am the child pid =-5428...
I am the parent
I am still the parent Sat Aug 25 20:29:13 2012
I am still the parent Sat Aug 25 20:29:15 2012
I am still the child  Sat Aug 25 20:29:16 2012
I am still the parent Sat Aug 25 20:29:17 2012
I am still the parent Sat Aug 25 20:29:19 2012
I am still the child  Sat Aug 25 20:29:20 2012
I am still the parent Sat Aug 25 20:29:21 2012
I am still the parent Sat Aug 25 20:29:23 2012
I am still the child  Sat Aug 25 20:29:24 2012
I am still the parent Sat Aug 25 20:29:25 2012
I am still the parent Sat Aug 25 20:29:27 2012
I am still the child  Sat Aug 25 20:29:28 2012
I am still the parent Sat Aug 25 20:29:29 2012
Terminating on signal SIGINT(2)
#I hit CTL-C in the command window...
#the parent was running in the foreground...

[BrowserUk]

# sleep() won't work on Windows in multiple threads ... there is Windows "weirdness" with sleep

Where did you get that from? Cos it's complete rubbish.

#/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:\test>junk57
I am the child pid =-3552...
I am the parent
I am still the child  Sun Aug 26 07:46:33 2012
I am still the parent Sun Aug 26 07:46:34 2012
I am still the child  Sun Aug 26 07:46:34 2012
I am still the child  Sun Aug 26 07:46:35 2012
I am still the parent Sun Aug 26 07:46:36 2012
I am still the child  Sun Aug 26 07:46:36 2012
I am still the child  Sun Aug 26 07:46:37 2012
I am still the parent Sun Aug 26 07:46:38 2012
I am still the child  Sun Aug 26 07:46:38 2012
Terminating on signal SIGINT(2)

BTW: The question above isn't sarcasm, but a real question.

I vaguely recollect hearing or reading someone else say something similar a long time ago, but I know it has never been true -- at least not since the long gone days of cooperative multithreading -- so I'd really like to know where the idea comes from?

[Marshall]

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.

Read more... (1297 Bytes)

[bojinlund]

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?

[BrowserUk]

I am completely flabbergasted why it did not work before.

Yeah! Me too.

[bulk88]

Perl sleep on windows in a VM or 100% CPU usage or C debugger breakpoints, or bad driver that likes lock all the CPUs and then spin sleep for too long to freeze the PC can cause an overflow in Perl's sleep, and then only a random Windows message (mouse move, repaint, idk what else, but there WILL be one, thx MS) will breakout of the sleep hang, see https://rt.perl.org/rt3/Ticket/Display.html?id=33096 causing the sleep to take more seconds than it should have. win32/win32.c#l2163 in perl.git for the offending code.

[BrowserUk]

Firstly, this perl-internals implementation bug is totally unrelated to the issue of whether "sleep work on multiple threads".

Secondly, the "bug" in that RT isn't a bug.

It basically says that sleep doesn't guarantee to return exactly when you asked for it to. But I'm not aware of any OS that gives such a guarantee, It is documented to sleep for at least the number of seconds requested.

It does not say that it will break out of a broken device driver, or debugger, nor VM, nor preempt a higher priority CPU-intensive thread or process.

I'm really confused why you thought it was relevant to raise that non-related, non-issue in this context?