I just found that Event goes into an endless polling loop whenever an error
occurs on a filehandle:
poll([{fd=3, events=POLLPRI|POLLOUT|POLLWRNORM|POLLRDBAND|POLLWRBAND,
revents=POLLERR|POLLHUP}], 1, 60000) = 1
gettimeofday({995996622, 745496}, NULL) = 0
poll([{fd=3, events=POLLPRI|POLLOUT|POLLWRNORM|POLLRDBAND|POLLWRBAND,
revents=POLLERR|POLLHUP}], 1, 60000) = 1
gettimeofday({995996622, 746308}, NULL) = 0
poll([{fd=3, events=POLLPRI|POLLOUT|POLLWRNORM|POLLRDBAND|POLLWRBAND,
revents=POLLERR|POLLHUP}], 1, 60000) = 1
gettimeofday({995996622, 747280}, NULL) = 0
without ever calling a callback. Reading the source I see that poll =>
'e' does not, as I anticipated, get called on error conditions (unless
select() is being used) but ONLY on high priority read data (interesting
side note: 'R' does not include high-priority read data but 'W' does
include high priority write data, which makes for some nice asymetry). If
an filehandle returns POLLHUP or POLLERR Event goes into an endless
CPU-eating poll-loop.
I temporarily worked around this bug by changing c/unix.c:141 from:
if (mask & (POLLRDBAND | POLLPRI)) got |= PE_E;
to
if (mask & (POLLRDBAND | POLLPRI | POLLERR | POLLHUP)) got |= PE_E;
however, wether this is the right fixc is the question: when select is
used, errors are reported using 'e', so it's probably the right thing
to do. I also think that the asymmetric distribution of POLLWRBAND
vs. POLLRDBAND is also not what is expected.
;)
HTH,
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
