This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt
Date 2013-01-09.21:28:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On Wed, Jan 9, 2013 at 12:47 PM, Charles-François Natali
<> wrote:
>> - How shall we go forward?  I've made a variety of small changes to the
>> Tulip version ( 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, 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
> 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:

>> - 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. :-)
Date User Action Args
2013-01-09 21:28:28gvanrossumsetrecipients: + gvanrossum, pitrou, giampaolo.rodola, christian.heimes, meador.inge, neologix, rosslagerwall, sbt, felipecruz
2013-01-09 21:28:28gvanrossumlinkissue16853 messages
2013-01-09 21:28:28gvanrossumcreate