[Libevent-users] How does libevent deal with more events than a particular syscall can handle?
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? -- Roger Clark [EMAIL PROTECTED] ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] How does libevent deal with more events than a particular syscall can handle?
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
Re: [Libevent-users] How does libevent deal with more events than a particular syscall can handle?
Has there ever been any mention of using IOCP or something on Windows? The Win32 implementation currently uses select() and still imposes the limit, which was mainly why I was asking. Furthermore, does there appear to be any activity on this project regarding Windows at all? -- Roger Clark [EMAIL PROTECTED] On 11/18/06, Steven Grimm <[EMAIL PROTECTED]> wrote: 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 ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] How does libevent deal with more events than a particular syscall can handle?
On Sat, Nov 18, 2006 at 05:53:24PM -0500, 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. Check out the C code; it's all there. :) On most platforms, the number of FDs passed to select() is not actually limited by the kernel; the only limitation is on the size of the fd_set structure. But libevent doesn't use fd_set. On unixlike systems, when select() is used, it builds its own bitfields; on Windows, it builds a counted array of fds. Of course, as noted, select() is very inefficient, and isn't used when libevent can avoid it. Check the list archives for some IOCP discussion. (Generally, it's a good idea to check the archives before posting about anything.) yrs, -- Nick Mathewson pgpq2XTaKTZU8.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] How does libevent deal with more events than a particular syscall can handle?
Roger Clark wrote: Has there ever been any mention of using IOCP or something on Windows? The Win32 implementation currently uses select() and still imposes the limit, which was mainly why I was asking. I've written IOCP code. It's in the hands of another list reader to get some testing; I'm not sure if he's had time or not, I emailed him last night and said if it's been tested, or can be tested in the next week, I'll wait, otherwise I intend to release the code for peer review. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users