[docs] [issue19876] selectors (and asyncio?): document behaviour on closed files/sockets
Guido van Rossum
report at bugs.python.org
Wed Dec 4 20:09:06 CET 2013
Guido van Rossum added the comment:
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:
if not mask:
self._selector.modify(fd, mask, (None, writer))
# unregister()/modify() may or may not raise this if
# the FD is closed -- it depends on what type of
# selector is used.
(and repeated in remove_writer()).
Python tracker <report at bugs.python.org>
More information about the docs