This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients giampaolo.rodola, gvanrossum, jcea, neologix, pitrou, sbt, trent
Date 2013-01-22.14:36:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0H21MYs6L1i+cPgtUNi-7hLyUCDzRrkRQiOSZ_150=7Q@mail.gmail.com>
In-reply-to <1358861470.65.0.64670252928.issue16507@psf.upfronthosting.co.za>
Content
> It appears that Linux's "spurious readiness notifications" are a deliberate deviation from the POSIX standard.  (They are mentioned in the BUGS section of the man page for select.)

I don't think it's a deliberate deviation, but really bugs/limitations
(I can remember at least one occurrence case where a UDP segment would
be received, which triggered a notification, but the segment was
subsequently discarded because of an invalid checksum). AFAICT kernel
developers tried to fix those spurious notifications, but some of them
were quite tricky (see e.g. http://lwn.net/Articles/318264/ for
epoll() patches, and
http://lists.schmorp.de/pipermail/libev/2009q1/000627.html for an
example spurious epoll() notification scenario).

That's something we have to live with (like pthread condition spurious
wakeups), select()/poll()/epoll() are mere hints that the FD is
readable/writable...

Also, in real code you have to be prepared to catch EAGAIN regardless
of spurious notifications: when a FD is reported as read ready, it
just means that there are some data to read. Depending on the
watermark, it could mean that only one byte is available.

So if you want to receive e.g. a large amount of data and the FD is
non-blocking, you can do something like:

"""
    buffer = []
    while True:
        try:
            data = s.recv(8096)
        except BlockingIOError:
            break

        if data is None:
            break
        buffer += data
"""

Otherwise, you'd have to read() only one byte at a time, and go back
to the select()/poll() syscall.

(For write ready, you can obviously have "spurious" notifications if
you try to write more than what is available in the output socket
buffer).

> Should I just apply the following patch to the default branch?

LGTM.
History
Date User Action Args
2013-01-22 14:36:41neologixsetrecipients: + neologix, gvanrossum, jcea, pitrou, giampaolo.rodola, trent, sbt
2013-01-22 14:36:41neologixlinkissue16507 messages
2013-01-22 14:36:41neologixcreate