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.