Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Getting around Win32 limitations

by Beatnik (Parson)
on Nov 09, 2002 at 22:52 UTC ( [id://211690]=perlquestion: print w/replies, xml ) Need Help??

Beatnik has asked for the wisdom of the Perl Monks concerning the following question:

I love programming on UN*X and it hurts me so much when I need to port code to Win32. My last effort tackled me at alarm. My original code used Time::HiRes and I really wanted to keep using it... Windows b0rked. I tried plain alarm. Windows b0rked. I'm eventually considering using the following snippet (which works since fork eventually was implemented in ActivePerl). Any other known tricks up anyone's sleeves? I'm still working on a work-around for a File::Find issue I'm having :(
#!perl $|++; if($pid = fork) { <STDIN>; kill 9,$pid; } else { while(1) { sleep(1); print "foo\n"; } }
Greetz
Beatnik
...Perl is like sex: if you're doing it wrong, there's no fun to it.

Replies are listed 'Best First'.
Re: Getting around Win32 limitations
by strat (Canon) on Nov 10, 2002 at 10:25 UTC
    Another idea might be waiting for perl5.8 (the first beta is out by http://www.activestate.com/). 5.8 allows alarm even under Win32, but I haven't yet tested how good it works...

    Best regards,
    perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

Re: Getting around Win32 limitations
by pg (Canon) on Nov 10, 2002 at 03:39 UTC
    What provided in this reply is garbage, but a small change should largely improve it. Use waitpid, instead of wait. If you call waitpid in this way: waitpid($child, 1), it will not blocking the main process. You just from time to time, come back and checking return code form this call, if it is -1, it means the child process died, and you get an alarm. This can be wrapped into an implementation of alarm, which is not implemented in active perl.
    my $child_pid = fork(); if ($child_pid) { $ret = wait($child_pid, 1); do { ... #whatever you want; } until ($ret == -1); print "got alarm\n"; } else { sleep($seconds); }
      I wrapped the thing up:
      alarm_pg.pm: package pg_alarm; use strict; sub new { shift; my $seconds = shift; my $self = {}; $self->{CHILD_PID} = fork(); if ($self->{CHILD_PID} == 0) { sleep($seconds); } bless $self; return $self; } sub alarmed { my $self = shift; my $result = 0; if (defined($self->{CHILD_PID})) { my $ret = waitpid($self->{CHILD_PID}, 1); if ($ret == -1) { $result = 1; } } return $result; } 1; test.pl: use pg_alarm; use strict; my $a = pg_alarm->new(10); while (!$a->alarmed()) { #print "haven't gotten alarm yet\n"; } print "got alarm\n";
Re: Getting around Win32 limitations
by pg (Canon) on Nov 10, 2002 at 17:28 UTC
    I realized that, my alarm_pg.pm has a problem. I have to add one line, highted below, so that the child process would stop right after the sleep. Otherwise, the child process will just continue to do whatever the program write for his main process. After a while, you will have lots of child processes running, and killing CPU's.
    alarm_pg.pm: package pg_alarm; use strict; sub new { shift; my $seconds = shift; my $self = {}; $self->{CHILD_PID} = fork(); if ($self->{CHILD_PID} == 0) { sleep($seconds);

    exit;
    } bless $self; return $self; } sub alarmed { my $self = shift; my $result = 0; if (defined($self->{CHILD_PID})) { my $ret = waitpid($self->{CHILD_PID}, 1); if ($ret == -1) { $result = 1; } } return $result; }
Re: Getting around Win32 limitations
by pg (Canon) on Nov 10, 2002 at 02:46 UTC
    Too bad, I hate the differences among platforms. Maybe this trick here can help:
    sub alarm my $child_pid = fork(); if ($child_pid) { wait; print "received alarm\n"; ... } else { sleep($seconds); }
Re: Getting around Win32 limitations
by Brutha (Friar) on Nov 10, 2002 at 18:50 UTC
    Be carefull with fork and signals under Windows.
    I did not get sensible results with that, it blocks or did not return (I did not try waitpid) so I stuck with the non-portable Win32-API, which changed the whole design of my application.

    All cookbook and other demos do work under Linux at home, but you have to test the basics under windows.

    Start a little test program before you think about a 'normal' design. Special OS need special treatment.

      Different OS needs different treatment.

      Try to think about it that way!

      Jenda

Re: Perl is like (was Re: Getting around Win32 limitations)
by Jenda (Abbot) on Nov 10, 2002 at 16:32 UTC

    I'd say ... Perl is like sex;, if you are doing it wrong, you may have fun, but the ones that try to do it with YOU will not.

    Jenda

      And this is relevant how?

        It's completely irrelevant of course.

        Just like the "What rap star as project manager" poll and about one fourth of all posts here :-)

        Jenda

Re: Getting around Win32 limitations
by bart (Canon) on Nov 12, 2002 at 01:59 UTC
    OK, fill me in. What File::Find issues? For all I know, File::Find works fine on Win32. Well, I had a case where it was so dead slow... that I made something very similar but based on Win32::API calls, and with an underlying directory entry object. You're welcome to the code, if that is indeed your problem.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://211690]
Approved by Aristotle
Front-paged by wil
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2024-03-28 17:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found