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 gvanrossum
Recipients docs@python, gvanrossum, neologix, vstinner
Date 2013-12-04.19:09:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1386184146.18.0.588608097024.issue19876@psf.upfronthosting.co.za>
In-reply-to
Content
The more I think about this the more I believe unregister() should catch the OSError (but not the KeyError).

Every unregister() implementation starts by calling super().unregister(key), which has a side effect (it removes the key from the _fd_to_key dict).

I believe that once this side effect has happened the unregister() call should return with success even if the kqueue syscall fails with OSError.

A further refinement could be to skip the kqueue syscall *if* the registered object is in fact an object with a fileno() method and not a bare FD, and the object is closed -- we should be able to tell that by calling its fileno() method, which should return -1 or None if it is closed.  (But this would be mostly an optimization -- and a safety guard in case the FD has been reused for a different object.)

I don't know how poll and epoll behave under these circumstances, but given that only the Kqueue-based asyncio test failed I think those don't raise when the FD has been closed.

If you are not amenable to this fix I will have to catch the OSError in Tulip's remove_reader(), e.g. like this:

            try:
                if not mask:
                    self._selector.unregister(fd)
                else:
                    self._selector.modify(fd, mask, (None, writer))
            except OSError:
                # unregister()/modify() may or may not raise this if
                # the FD is closed -- it depends on what type of
                # selector is used.
                pass

(and repeated in remove_writer()).
History
Date User Action Args
2013-12-04 19:09:06gvanrossumsetrecipients: + gvanrossum, vstinner, neologix, docs@python
2013-12-04 19:09:06gvanrossumsetmessageid: <1386184146.18.0.588608097024.issue19876@psf.upfronthosting.co.za>
2013-12-04 19:09:06gvanrossumlinkissue19876 messages
2013-12-04 19:09:05gvanrossumcreate