>I do have a productive suggestion though that we kicked around once or >twice. Spin up helper threads (we can even keep a cache of them) to >handle each group of 64 events, and have them pop an event to the >parent thread once finished. at 64x63 events, this could be quite >respectible.
This is a very bad idea, it would be better to use overlapped IO and focus on when requests complete and work on that model, and deprecate poll or fake it with a buffer to handle the mismatch between 'done' and 'try now'. >Keep in mind, as you consider new designs for apr_poll, that the >longest standing issue is polling on files. If you can solve both >issues in one whack, we would trip over each other getting your >patch committed :) Isn't poll on files more a theoretical benefit than actual, since they always signal as ready? James
