[tpop3d-discuss][PATCH]: poll for tpop3d

Chris Lightfoot chris at ex-parrot.com
Sun, 25 Jun 2006 23:04:17 +0100


On Sun, Jun 25, 2006 at 10:30:50PM +0200, Arkadiusz Miskiewicz wrote:
> On Saturday 24 June 2006 19:46, Chris Lightfoot wrote:
> > On Thu, Jun 22, 2006 at 08:28:04PM +0200, Arkadiusz Miskiewicz wrote:
> 
> > > > applied in CVS, with a poll(2) wrapper and autoconf test.
> > > > Please test ;-)
> > >
> > > Version from cvs works for me.  There is one thing in my patch which
> > > could be nicer - match existing code like using xcalloc and xfree instead
> > > of malloc and free.
> > >
> > > ps. another patch for consideration:
> > > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/tpop3d-disable-dotfile-lo
> > >cking.patch by heretyk@pld-linux.org
> >
> > Now also applied in CVS.
> 
> Please apply this one, too:
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/tpop3d-poll.patch?rev=1.10
> 
> It fixes:
> - use poll when available (right now we were always using select fallback)

d'oh.

> - fix for case when revents contain more than one event (I guess that's 
> possible)

definitely.

> - set descriptors to -1 so kernel can skip them when doing poll()

ok.

> - the second parameter of poll is highest possible index in an array (no need 
> to +1)

ok.

One more thing -- as it stands, the code tests only for
POLLIN, and not for POLLHUP; this mirrors the select(2)
semantics where a socket which has been closed (or
generally a fd at EOF) is marked as readable. However, in
poll(2) a fd at EOF should have POLLHUP asserted in the
revents field, so far as I understand this:
    http://www.opengroup.org/onlinepubs/009695399/functions/poll.html

So there are two issues here: firstly, the tests for
POLLIN should (because of the way the code was written)
test for POLLIN|POLLHUP. Secondly, the wrapper function in
poll.c should honour the poll(2) semantics.  That's
slightly irritating, because I can't see a nice way to
distinguish the two conditions (socket readable and socket
at EOF) using select(2). A nasty possibility would be to
call recv(2) with MSG_PEEK for each `readable' socket, but
that's horrid. It's not immediately important, but
something to bear in mind for future development, since
we've shifted to the poll(2) semantics over those of
select(2).

-- 
``The fascination of shooting as a sport depends almost wholly
  on whether you are at the right or wrong end of the gun.'' (P G Wodehouse)