Re: UDP recvmsg blocks after select(), 2.6 bug?

[Adrian Phillips]

>>>>> "Andries" == Andries Brouwer <aebr@xxxxxxxxxx> writes:

    Andries> On Wed, Oct 06, 2004 at 02:18:23PM -0600, Chris Friesen
    Andries> wrote:
    >> In any case, the current behaviour is not compliant with the
    >> POSIX text that Andries posted.  Perhaps this should be
    >> documented somewhere?

    Andries> For the time being I wrote (in select.2)

    Andries> BUGS It has been reported (Linux 2.6) that select may
    Andries> report a socket file descriptor as "ready for reading",
    Andries> while nev- ertheless a subsequent read blocks.  This
    Andries> could perhaps happen when data has arrived but upon
    Andries> examination has wrong checksum and is discarded. Thus it
    Andries> may be safer to use non-blocking I/O.

On my Debian stable and testing boxes the following text is in man 2
select (obtained from ftp://ftp.win.tue.nl/pub/linux-local/manpages)
:-

       Three independent sets of descriptors are watched.  Those listed in readfds will be watched to
       see  if  characters  become  available  for reading (more precisely, to see if a read will not
                                                                                        ^^^^^^^^^^^^^
       block - in particular, a file descriptor is also ready on end-of-file), those in writefds will
       ^^^^^

(and seems to be the same in the latest tarball) which means that
there is a good possibility that a number of people, myself including,
rely on read not blocking on a fd after select indicates that
"characters have become available". This section should be altered in
some way as well (perhaps referencing the BUGS section).

Sincerely,

Adrian Phillips

-- 
Who really wrote the works of William Shakespeare ?
http://www.pbs.org/wgbh/pages/frontline/shakespeare/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/