Detection of subsequent data by poll()

[brueckd at tbye.com]

On 6 Dec 2001, Rupert Scammell wrote:

> Donn Cave <donn at u.washington.edu> wrote in message news:<9um3qr$d20$1 at nntp6.u.washington.edu>...
> > Quoth rupe at metro.yak.net (Rupert Scammell):
> > | I recently wrote a program that uses the select.poll() method in order
> > | to
> > | check for incoming data on multiple listening sockets.  When I open a
> > | connection to one of the listening sockets (e.g. via telnet), the
> > | program accepts the first item of data sent (a character string with a
> > | trailing CRLF).  However, subsequent calls to poll() never appear to
> > | detect more strings sent in the same connection to this socket.  The
> > | file descriptors for the sockets are all correctly registered with the
> > | poll object.
> > |
> > | Is there a way to make poll() detect this incoming data without having
> > | to close and re-open a connection to the socket in question each time?
> > |
> > | Any suggestions would be appreciated!
> >
> > Suggestion:  post a program that shows the problem.  Also suggest
> > you mention your platform.
> >
> > 	Donn Cave, donn at u.washington.edu
>
> Per Donn Cave's request, the source of the program that's producing
> the problem is provided below.  The system in use is a RH Linux 6.2
> machine (x86 architecture), running kernel version 2.4.13.  Again, any
> assistance or insight into why the poll() call made against the poll
> object is failing to return more than the first sent line of data
> would be greatly appreciated.
<snip>

Hi Rupert,

It looks like the new sockets never get registered with the poller. The
original listener sockets do, but not the ones you're getting from the
call to accept().

HTH,
Dave

P.S. - it'd be safer to not call recv on the newly-accepted sockets until
after you've registered them with the poller, called poll, and then
received a data-ready-to-be-read (select.POLLIN) event for that socket,
otherwise you could end up blocking everything waiting for data. Or, make
the new sockets nonblocking (s.setblocking(0)) and try the read but be
sure to catch the associated exception if no data is ready.