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 gvanrossum, neologix, vstinner
Date 2013-10-31.23:36:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJK42DfH=7MHk3WHJgzCBdOkOE9Lb_iU5COVxGwNvEz1Jg@mail.gmail.com>
In-reply-to <1383260353.22.0.783819472357.issue19465@psf.upfronthosting.co.za>
Content
Hm... I'm trying to understand how you're using the selector in
telnetlib.py (currently the only example outside asyncio). It seems you're
always using it with a single file/object, which is always 'self' (which
wraps a socket), except one place where you're also selecting on stdin.
Sometimes you're using select(0) to check whether I/O is possible right
now, using select(0), and then throw away the selector; other times you've
got an actual loop.

I wonder if you could just create the selector when the Telnet class is
instantiated (or the first time you need the selector) and keep the socket
permanently registered; IIUC selectors are level-triggered, and no
resources are consumed when you're not calling its select() method. (I
think this means that if the socket was ready at some point in the past,
but you already read those bytes, and now you're calling select(), it won't
be considered ready even though it was registered the whole time.)

It still seems to me that this is pretty atypical use of selectors; the
extra FD used doesn't bother me much, since it doesn't really scale anyway
(that would require hooking multiple Telnet instances into the the same
selector, probably using an asyncio EventLoop).

If you insist on having a function that prefers poll and select over kqueue
or epoll, perhaps we can come up with a slightly higher abstraction for the
preference order? Maybe faster startup time vs. better scalability? (And I
wouldn't be surprised if on Windows you'd still be better off using
IocpProactor instead of SelectSelector -- but that of course has a
different API altogether.)
History
Date User Action Args
2013-10-31 23:36:33gvanrossumsetrecipients: + gvanrossum, vstinner, neologix
2013-10-31 23:36:33gvanrossumlinkissue19465 messages
2013-10-31 23:36:33gvanrossumcreate