[Libevent-users] How does libevent deal with more events than a particular syscall can handle?

[Steven Grimm]

It avoids using select() unless there's absolutely no other choice, in 
part because of the artificial limits of select() but mostly because 
select() is inefficient for large numbers of monitored file descriptors.

Most of the point of libevent is that it's a generic wrapper around 
OS-specific event notification mechanisms that don't have the kinds of 
problems select() has. It will use the best available mechanism on 
whatever platform you're on. I can't say anything about Win32 in 
particular, but most platforms at the very least support poll(), which 
shares some of select()'s efficiency problems but at least doesn't have 
a small compile-time limit on the number of pollable file descriptors. 
All the significant modern UNIX-ish platforms support much better 
mechanisms than poll(): kqueue on BSD, event ports on Solaris, epoll on 
Linux, etc. If you're coding to libevent's API you don't have to worry 
about the details of the underlying notification mechanism.

-Steve


Roger Clark wrote:
> For instance, the maximum number of fds usable by select() on Win32
> (or other platforms) is low compared to the number of potential
> connections needed by a high-throughput HTTP server.
>
> Does libevent call the dispatcher multiple times on different sets of
> events? How does the design of the library compensate for this?
>