Charles-François Natali added the comment: There are actually two reasons to choosing poll over epoll/kqueue (i.e. no extra FD): - it's a bit faster (1 syscall vs 3) - but more importantly - and that's the main reason I did it in telnetlib/multiprocessing/subprocess - sometimes, you really don't want to use an extra FD: for example, if you're creating 300 telnet/subprocess instances, one more FD per instance can make you reach RLIMIT_NOFILE, which makes some syscalls fail with EMFILE (at work we have up to a 100 machines, and we spawn 1 subprocess per machine when distributing files with bittorrent).
So I agree it would be nice to have a better way to get a selector not requiring any extra FD. The reason I didn't add such a method in the first place is that I don't want to end up like many Java APIs: Foo.getBarFactory().getInstance().initialize().provide() :-) > I read somewhere that differenet selectors may have different limits on the > number of file descriptors. Apart from select(), all other selectors don't have an upper limit. As for the performance profiles, depending on the application usage, select() can be faster than poll(), poll() can be faster than epoll(), etc. But since it's really highly usage-specific - and of course OS specific - I think the current choice heuristic is fine: people with specific needs can just use PollSelector/EpollSelector themselves. To sum up, get_selector(use_fd=True) looks fine to me. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19465> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com