BUG: nice => 1 causes event handler to be called multiple times

[Marc Lehmann]

Hi!

When I use the following code to accept new conections, everything works:

use Socket;
use IO::Socket::INET;

our $LISTEN = new IO::Socket::INET
LocalPort => 13327,
Listen => 1,
ReuseAddr => 1;

Event->io (fd => $LISTEN, nice => 0, poll => 'r', data => 1, cb => sub {
my ($fh, $peername) = $LISTEN->accept
or return;
});

However, when I change the nice => 0 by nice => 1, the program blocks in accept in
about every 10th or so connect. strace -fepoll,accept shows this:

[pid 18564] poll([{fd=8, events=POLLIN|POLLPRI, revents=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI}], 3, 0) = 1
[pid 18564] accept(8, {sa_family=AF_INET, sin_port=htons(44238), sin_addr=inet_addr("10.0.0.1")}, [566935683088]) = 4
[pid 18564] poll([{fd=9, events=POLLIN|POLLPRI, revents=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI}], 4, 0) = 1
[pid 18564] accept(8,

As you can see, there is a single new connection, the handler gets called,
accept()'s and everything is fine.

On the next poll, the filehandle (fd 8) is NOT ready, but the handler
_still_ gets callefd and naturally blocks in accept until a new conenction
arrives, halting the program.

This is dependent on nice => 1, with nice => 0, it works everytime.

A quick guess of what might have happened (without looking at the code)
is that Event somehow confuses the first and the second poll result: with
nice => 0, fd 8 is always first in poll, with nice => 1, fd 8 sometimes
gets moved intot he second slot, and everytime this happens, I get the
problem.

This is just a quick guess at whats happening.

--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ p...@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE

[Marc Lehmann]

On Sat, Dec 23, 2006 at 04:18:58AM +0100, Marc Lehmann <sch...@schmorp.de> wrote:
> is that Event somehow confuses the first and the second poll result: with
> nice => 0, fd 8 is always first in poll, with nice => 1, fd 8 sometimes
> gets moved intot he second slot, and everytime this happens, I get the
> problem.
>
> This is just a quick guess at whats happening.
> A quick guess of what might have happened (without looking at the code)

The same bug happens when I force the use of select instead of poll:

select(9, [5 7 8], [], [], {0, 0}) = 1 (in [8], left {0, 0})
accept(8, {sa_family=AF_INET, sin_port=htons(46735), sin_addr=inet_addr("10.0.0.1")}, [566935683088]) = 4
select(10, [5 7 8 9], [], [], {0, 0}) = 1 (in [9], left {0, 0})
accept(8,