[llimllib]

> => "I'll pick the best one for the environment"

Which, in reality is, "I'll spend a lot of design and implementation effort designing a new one which may or may not improve the measurable, global performance of my new web server because it's not yet at the point where I can benchmark these sorts of things to verify that I'm not wasting a whole ton of effort that could be better spent by deciding that epoll is fast enough."

Maybe Zed knows from his previous server experience that {e}poll is where he hits a bottleneck; it's just that if there's any chance that it's not, he could be wasting a bunch of time implementing "superpoll".

(Or maybe he just wants to do it because it's neat, or because it's innovative (which it is), or for any number of other reasons. I'm just pointing out that he's doing much more than picking "the best one for the environment")

[zedshaw]

It's an idea I had after actually measuring. If it doesn't work then I tried something out.

What you really should be getting from it though is that epoll is not faster. It is not O(1). It is not faster on smaller vs. larger lists of FDs. Pretty much all the things you were told as advantages of epoll are total crap.

The only advantage of epoll is it's O(N=active) when poll is O(N=total). That's it.

So at a minimum I've done some education and spent some time learning something.

[llimllib]

I tried to make sure I gave lots of reasons that justify your work; I do think it's cool.

I just wanted to say that it is not an unquestionable design decision.

Rock on with the superpoll, I hope it's awesome and very successful.

[axod]

... or it's good "PR" so people get behind the project. It screams "I know what I'm doing!!! I'm even optimizing this!!!". ;)