Comment 15 for bug 1112195

I'd be happy to put my five cents worth in with respect to the API design.

As to the select() style API, my gut feeling is that it's cleaner and easier to do the same thing with threads. The whole select() interface primarily came about because there were no threads back then.

For truly large numbers of things to monitor, threads won't do the job. But select() doesn't do the job either because it doesn't scale. We used epoll() in Ice to get scalability. (We stopped testing after we had more than 100000 connections into a single server process because we ran out of hardware resources to test with, not because Ice wouldn't scale any more.)

But, for async calls, scalability is not an issue. I doubt that people would ever have more than a handful of results outstanding at any one time.

I'd be inclined to hold any select() API at arm's length until there is clear use case for it, and then design an API to meet the use case, rather than designing something to meet an anticipated need that might never come about.