Guido van Rossum added the comment: On Wed, Jan 9, 2013 at 12:47 PM, Charles-François Natali <rep...@bugs.python.org> wrote: >> - 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?
Sure. I think in terms of API, it is pretty good except for the 'connect' issue below (and the related issue of a WSAPoll() wrapper, which Tulip had before the switch). In terms of implementation, I expect there's plenty to do, but it will be a long time before we'll know. It's probably best to do this incrementally. There's also the question of IOCP support, but I expect that it is too unwieldy to add to the select module -- it'll be a separate project. Hopefully Richard can help with this. > 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? I like the longer names, EVENT_READ; they aren't used enough to need abbreviating, and it's always hard to remember exactly what abbreviation is used. > - 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). I'm not sure what the pros and cons would be of doing this for all syscall wrappers, but I do know I want Tulip to work with Python 3.3 out of the box, so we need to add this to the select() calls. I imagine it's a bit tricky to test... Maybe I could use alarm() or setitimer() for testing? > 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 know. :-( >> - 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? Sounds good. >> - 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. Just check out the last rev of Tulip before I switched: http://code.google.com/p/tulip/source/browse/tulip/unix_events.py?spec=svn28b7efd465b8529cdaa34e6b710f291c835c657b&r=28b7efd465b8529cdaa34e6b710f291c835c657b >> - Have you submitted a PSF contributor form yet? (Probably yes, years ago, >> just making sure. :-) > > Actually, I already have commit rights ;-) Doesn't surprise me. :-) ---------- _______________________________________ 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
