Guido van Rossum added the comment: > The problem is that for epoll (and kqueue I think) the FD is > automagically removed from the backend, which means that we won't get > any notification for this FD, hence we're unable to report it as > closed.
That makes it sound like it will be hard to respond the same way on all platforms. :-( Even silently removing the registration for select and poll still leaves the behavior different: if you register a bad FD with select or poll, the register() call will accept it but the select() call will silently remove it; however if you register a bad FD with epoll or kqueue, register() will raise EBADF. I would prefer to see an EBADF exception in all four cases, even if it happens in register() for some platforms and in select() for others. There is also the issue of trying to unregister (or modify?) an FD that has gone bad after successful registration -- this will also have different behavior on the different platform, right? Maybe we'll get better design guidance if we look at this from the POV of a server loop that doesn't fully control the code that may be registering and unregistering FDs. It seems a good idea to make it so that if some bad piece of code tries to register a bad FD or close a FD without unregistering doesn't bring down the entire server, but the bad code always sees an exception. Maybe we should be silent in select() but cause unregister() to fail? ---------- _______________________________________ 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
