Skip Menu |
 

This queue is for tickets about the IO CPAN distribution.

Report information
The Basics
Id: 25049
Status: resolved
Priority: 0/
Queue: IO

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.22
Fixed in: (no value)



Subject: IO::Poll->poll() with no handles always returns immediately
Using IO::Poll version 0.07, I notice that if I have $poll as an IO::Poll object with not yet any file handles in it, $poll->poll( 10 ); returns 0 immediately, rather than doing what a C programmer would expect; namely, sleeping for upto 10 seconds anyway. I notice this comes from the following source line (IO/Poll.pm line 86): my $ret = @poll ? _poll(defined($timeout) ? $timeout * 1000 : -1,@poll) : 0; Could it simply be changed to always call _poll() even if the @poll array is empty? Or does some underlying code rely on there being something in there? Failing that, would it be possible to deteriorate it to a sleep or select call instead? One of the following perhaps: my $ret = @poll ? _poll(...) : sleep( $timeout ); or my $ret = @poll ? _poll(...) : select(undef,undef,undef, $timeout * 1000 ) noting that the former case using sleep() does not properly handle timeouts of greater resolution than one second, unless the Time::HiRes module is used, but perhaps IO::Poll shouldn't depend on that. -- Paul Evans
Download (untitled) / with headers
text/plain 836b
On Tue Feb 20 09:41:10 2007, PEVANS wrote: Show quoted text
> Could it simply be changed to always call _poll() even if the @poll > array is empty? Or does some underlying code rely on there being > something in there? > > Failing that, would it be possible to deteriorate it to a sleep or > select call instead? One of the following perhaps: > > my $ret = @poll ? _poll(...) > : sleep( $timeout ); > > or > > my $ret = @poll ? _poll(...) > : select(undef,undef,undef, $timeout * 1000 )
Is there any update on this yet? I had a run-away process today spinning 100% CPU because of this behaviour; it would be nice to get it fixed. Perhaps if you want to suggest some advice on which approach is best, I can write a patch and some tests for it, which you can then include in the next update. -- Paul Evans
Subject: Re: [rt.cpan.org #25049] IO::Poll->poll() with no handles always returns immediately
Date: Fri, 23 Jan 2009 12:56:39 -0600
To: bug-IO [...] rt.cpan.org
From: Graham Barr <gbarr [...] pobox.com>
On Jan 23, 2009, at 12:22 PM, Paul Evans via RT wrote: Show quoted text
> Queue: IO > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=25049 > > > On Tue Feb 20 09:41:10 2007, PEVANS wrote:
>> Could it simply be changed to always call _poll() even if the @poll >> array is empty? Or does some underlying code rely on there being >> something in there? >> >> Failing that, would it be possible to deteriorate it to a sleep or >> select call instead? One of the following perhaps: >> >> my $ret = @poll ? _poll(...) >> : sleep( $timeout ); >> >> or >> >> my $ret = @poll ? _poll(...) >> : select(undef,undef,undef, $timeout * 1000 )
> > Is there any update on this yet? I had a run-away process today > spinning > 100% CPU because of this behaviour; it would be nice to get it fixed. > > Perhaps if you want to suggest some advice on which approach is > best, I > can write a patch and some tests for it, which you can then include in > the next update.
To fix it would imply the current implementation is a bug and I a not sure I agree it is. Graham.
Download (untitled) / with headers
text/plain 1.6k
On Fri Jan 23 13:57:21 2009, gbarr@pobox.com wrote: Show quoted text
> To fix it would imply the current implementation is a bug and I a not > sure I agree it is.
In C-land, both the select() and the poll() calls wait for {file IO, timeout, signal}. You can make a select() or poll() call with no filehandles, or no timeout, or with signals blocked, and still await the other two. It's simple and orthogonal. Your main event loop can be small and simple because you don't, at the select()/poll()-call time, have to care about which subset of events you're currently waiting on. The same applies to select() in Perl - the following makes sense # wait for timeout or signal my $ret = select(undef,undef,undef, $timeout); However, your poll() wrapper does not. It breaks this orthogonality by special-casing the "no file handles" case, going out of its way to do this specially. This means, my code has to go out of its way to put the orthogonality back. From IO::Async::Loop::IO_Poll: 207 # There is a bug in IO::Poll at least version 0.07, where poll() with no 208 # registered masks returns immediately, rather than waiting for a timeout 209 # This has been reported: 210 # http://rt.cpan.org/Ticket/Display.html?id=25049 211 if( $poll->handles ) { 212 $pollret = $poll->poll( $timeout ); ... 226 } 227 else { 228 # Workaround - we'll use select() to fake a millisecond-accurate sleep 229 $pollret = select( undef, undef, undef, $timeout ); 230 } I can then test $pollret for >0, 0, or -1/EINTR, which indicates file IO, timeout, signal respectively. It would be nice for everyone who uses IO::Poll not to have to go out of their way like this. -- Paul Evans


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.