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

2006-11-18 Thread Roger Clark

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?

2006-11-18 Thread 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?



___
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?

2006-11-18 Thread Roger Clark

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?

2006-11-18 Thread Nick Mathewson
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