Charles-François Natali added the comment: > - How shall we go forward? I've made a variety of small changes to the > Tulip version (selector.py) now. Can you work those into a fresh unified > patch for CPython 3.4?
Yes, but I think we could wait a little, to make sure the API is good enough to fulfill all tulip's need? There are a couple things I'm not completely happy with: - if we add a CONNECT event, then I think SELECT_IN/SELECT_OUT aren't good names anymore: I think that EVENT_READ/EVENT_WRITE/EVENT_CONNECT would be more consistent (since it embeds the operation that should now succeed on the socket). Maybe even shorter names like EVT_READ? - right now, selectors don't handle EINTR, which means that upon reception of a signal, Selector.select() can fail with EINTR (the original tulip implementation also had this problem). I've been more or less midly advocating to change all Python syscalls wrappers to handle EINTR because it's really just a nuisance, but I think Selector.select() should definitely handle EINTR and retry the syscalls (with an updated timeout). Note: the test testAddSignalHandler() added recently doesn't demonstrate this problem because os.kill(os.getpid(), signal.SIGINT) because the signal is delivered synchronously (when kill() syscall returns to user-space), before select()/poll()/epoll() gets called. > - I'll change _Key to Key in the Tulip copy (though I wonder if maybe it > should be a longer name -- 'Key' is rather generic). SelectorKey, or something along those lines? > - Are you going to implement the SELECT_CONNECT flag? Unfortunately, I don't know anything about Windows, so I won't be able to. But I guess that porting Pollster.WSAPollster to selectors shouldn't be too hard. > - Have you submitted a PSF contributor form yet? (Probably yes, years ago, > just making sure. :-) Actually, I already have commit rights ;-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16853> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
