IIUC - there are -very- few cases where you need a massive array of poll/select objects, because in most cases it's not practical with a threaded architecture.
Cases in point; the httpd listen pool, the jni listen pool. Any other good examples? I'm thinking we need to start from square one on an API that can be optimally built for the various unix async models, win32, and a classic poll or select platform. In almost all the cases a single object of work is returned, spun off to a worker thread, and then returned to the pool. Our current API is certainly sub-optimal for this, across the board. Bill
