On Wed, Jan 9, 2013 at 12:47 PM, Charles-François Natali
<report@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. :-)