Message205233
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()). |
|
Date |
User |
Action |
Args |
2013-12-04 19:09:06 | gvanrossum | set | recipients:
+ gvanrossum, vstinner, neologix, docs@python |
2013-12-04 19:09:06 | gvanrossum | set | messageid: <1386184146.18.0.588608097024.issue19876@psf.upfronthosting.co.za> |
2013-12-04 19:09:06 | gvanrossum | link | issue19876 messages |
2013-12-04 19:09:05 | gvanrossum | create | |
|