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?
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
