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 neologix
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt
Date 2013-01-07.09:31:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> Also notice the need for a third constant, SELECT_CONNECT.  For details see the class WindowsPollPollster in the Tulip code.

I'll trust Richard on all Windows matter, so if you need a
SELECT_CONNECT constant, I'll expose one.

> However, two Tulip tests are now failing:

I can't reproduce those failures on Linux (I had to adapt the
hostnames because I'm at work and my test machine can't access the
internet, but otherwise everything is the same). All tests pass with
select, poll and epoll.

Note that I had to fix a typo in the patch: EPollSelector -> EpollSelector.

> - tulip.events_test.PollEventLoopTests.testCreateSslTransport fails with spurious file descriptors returned by poll() that aren't in the _fd_to_key dict (but the corresponding test with Select passes)
> The first failure has this traceback:
> Traceback (most recent call last):
>   File "/Users/guido/tulip/tulip/", line 178, in _key_from_fd
>     return self._fd_to_key[fd]
> KeyError: 0
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
>   File "/Users/guido/tulip/tulip/", line 216, in testCreateSslTra\
> nsport
>   File "/Users/guido/tulip/tulip/", line 120, in run
>     self._run_once()
>   File "/Users/guido/tulip/tulip/", line 592, in _run_once
>     event_list =
>   File "/Users/guido/tulip/tulip/", line 255, in select
>     key = self._key_from_fd(fd)
>   File "/Users/guido/tulip/tulip/", line 180, in _key_from_fd
>     raise RuntimeError("No key found for fd {}".format(fd))
> RuntimeError: No key found for fd 0
> (But the fd value varies -- sometimes it is -2, sometimes a large number.)

This failure is really weird, because the file descriptor is really
just the value returned by poll.poll(): I don't know how this could
possibly ever be negative, unless some sort of overflow in the
poll.poll() code itself?

I can however see why the previous version wouldn't fail:
        for fd, flags in self._poll.poll(msecs):
            if flags & ~select.POLLOUT:
                if fd in self.readers:
            if flags & ~select.POLLIN:
                if fd in self.writers:

If a spurious fd is reported, it's silently ignored.

The second test runs fine on Linux, and from a cursory look, I don't
see how it could fail (the socket should be reported as write ready

I'll try running the exact test case with the same hostnames from
home, but I doubt it'll make a difference, so maybe it's really OS-X
specific (if there's strace/dtrace on OS-X, it'll help see what's
going on).
Date User Action Args
2013-01-07 09:31:26neologixsetrecipients: + neologix, gvanrossum, pitrou, giampaolo.rodola, christian.heimes, meador.inge, rosslagerwall, sbt, felipecruz
2013-01-07 09:31:26neologixlinkissue16853 messages
2013-01-07 09:31:24neologixcreate