On Tue, May 30, 2006, Henrik Nordstrom wrote: > - Some benchmarking is needed to see if comm_poll is really worth to > keep, or if comm_select is actually better. The current comm_poll > implementation looks extremely inefficient (same as it always been in > 2.x)..
Poll should be better - it'll be much better if/when the comm backon/backoff stuff is turned on by default and can be used to add/subtract pollfd entries. I'm sure a little coding can go a long way in improving poll and select. I had some paper scribbles for how to do it before the SSL stuff went in. I also had some checks to make sure delay pools kept working. I'm now not so sure and won't be until after exams are over. I'll vote to keep it in there. I'll attempt to tidy the code up after exams whether or not its done in the 2.6-stable release timeframe. Adrian
