serious bug in Event's poll implementation

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                       |
                                                         |