Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^4: IO::Select and alarm()

by markseger (Beadle)
on Nov 01, 2011 at 14:33 UTC ( #935131=note: print w/ replies, xml ) Need Help??


in reply to Re^3: IO::Select and alarm()
in thread IO::Select and alarm()

I just spotted this note and have a couple of questions on this myself. I have a piece of code that also uses can_read() and needs to deal with signals. Or does it?

My code is actually modeled after the example in the IO:Select man page here - http://perldoc.perl.org/IO/Select.html which does not do anything special about premature wakeup:

while(@ready = $sel->can_read) { foreach $fh (@ready) { if($fh == $lsn) { # Create a new socket $new = $lsn->accept; $sel->add($new); } else { # Process socket # Maybe we have finished with the socket $sel->remove($fh); $fh->close; } } }

Since my code DOES seems to work correctly, even when dealing with hundreds of connections while an alarm is going off every second, my question becomes WHY does it work when I'm not paying any attention to EINTR? Am I just lucky - I highly doubt it? A number of people have been using this code for years...

When I instrumented the code it looks like the timer interrupt is indeed waking it from the can_read(). But then it immediately falls through the loop and cycles around back to the can_read(), and also wakes when there real data to process and deal with it appropriately.

As an aside, I also did try the recommended way for doing this, which pays attention to EINTR, and that works as well. So the questions then become is one way preferred to the other and why does my code, written the way it is, seem to be rock solid?

-mark


Comment on Re^4: IO::Select and alarm()
Download Code
Re^5: IO::Select and alarm()
by ikegami (Pope) on Nov 01, 2011 at 19:56 UTC

    Since my code DOES seems to work correctly,

    $ perl -MIO::Select -E' my $sel = IO::Select->new(\*STDIN); $SIG{ALRM} = sub { }; alarm(1); while (my @ready = $sel->can_read()) { # ... } say "HERE"; ' HERE

    The OP doesn't want to reach HERE, but apparently that's not a problem for you.

      ikegami: good example, but I'm not sure what you're trying to show me. Clearly the alarm is waking up the select but I already knew it does.

      I think the bigger question is when it wakes it up do you explicitly need to ignore the alarm inside the select loop? From my experiments, and if you put a print inside the loop, the code inside the loop doesn't execute (I assume this is because @ready is empty at this point), but I'm not sure whether this example is sufficient to prove it and think that is the key question, though it clearly operates as I've seen with my tests.

      -mark

        but I'm not sure what you're trying to show me.

        It shows the select loop being exited. As I said, the OP did not want to exit the select loop.

        I think the bigger question is when it wakes it up do you explicitly need to ignore the alarm inside the select loop?

        If you don't, the select loop is exited, so you're asking why there is a need to not exit the select loop.

        I don't believe there is such a universal need. Like I said, the OP has such a need, but apparently you don't.


        That said, I suspect you didn't actually show your entire select loop, and that you actually ignore *all* errors. If so, you would also be ignoring EINTR just like I told the OP to do.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://935131]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-12-21 22:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (108 votes), past polls