Guido van Rossum added the comment: Eww, sorry. That's the second time I mistook this thread for the other. I re-read the original description and I now think that we should follow your original advice.
There are two separate cases: (1) Registering an invalid FD; this succeeds for select/poll, fails for epoll/kqueue. (2) Registering a valid FD, then closing it, then calling <selector>.select(); this raises for select, returns a special event for poll, and is silently ignored for epoll/kqueue. I agree on making all selectors do the same thing for (2), and I agree that the best thing is to be silent and unregister the bad FD if we can (IIUC epoll/kqueue don't even tell us this happened?). We then need to make unregister() be silent when the FD isn't registered. Maybe make it return True when it actually unregistered something and False when there's nothing? An alternative would be to put the bad FD into a separate "quarantine" set so that it won't be used by the select() method but will still be recognized by unregister(). (And register() should look there too.) This still leaves case (1), where the FD is already bad when we register it. I am actually fine with sometimes raising and sometimes not; I don't want to pay the extra overhead of doing an fstat() or some other syscall just to verify that it is valid. (Although this would make the argument about wanting to choose a selector class that doesn't make extra syscalls less compelling. :-) And neither do I want to ignore the error in register() and pretend success. I guess we should in any case make it consistent so that if you successfully register() an FD you can always unregister() it without raising. I really wish there was an event to tell us that an FD has become invalid, but if epoll/kqueue really don't support that, i don't think it's worth it to introduce that only for select/poll. IOW let's do what those other systems you mention do. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19017> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
