Date: Wed, 25 Apr 2001 13:49:02 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: "Andrew R. Reiter" <arr@watson.org> Cc: freebsd-arch@FreeBSD.ORG, provos@openbsd.org Subject: Re: libevent & fbsd Message-ID: <20010425134902.S1790@fw.wintelcom.net> In-Reply-To: <Pine.NEB.3.96L.1010425161957.40963B-100000@fledge.watson.org>; from arr@watson.org on Wed, Apr 25, 2001 at 04:26:32PM -0400 References: <Pine.NEB.3.96L.1010425161957.40963B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
cc'd Niels Provos.
* Andrew R. Reiter <arr@watson.org> [010425 13:26] wrote:
> Hey,
>
> Im doing some -audit work and Im about to start writing some patches to
> change alot of the select(2) calls to use k{queue,event}(). Niels Provos
> has started writing (or has semi-finished a release, afaik) of his
> libevent code. Basically it's a general interface to multiple types of
> event handling code (select(), poll(), kqueue/event) on file descriptors.
> I am interested in using something like this, possibly, instead of hacking
> through some of the code and moving kqueue/event into them.
>
> I am wondering if anyone has spoken to Niels about perhaps getting it into
> our tree? or if anyone has any thoughts on this at all? :-)
>
> The url for the code is:
>
> http://www.monkey.org/~provos/libevent/
Niels, please excuse me if I'm jumping to conclusions here, and I
realize that the library seems to be in very early beta form (ver
0.3), however, it looks like libevent's model is not complex enough
to support effecient use of kqueue. This is because EV_ONESHOT is
always OR'd into the event flags, espcially when EV_READ is called
for.
What you really want to do is provide a way to keep a generic list
of "constantly polled fd" within your library. The idea is for
instance you have an application (take IRCd for instance) where
you have several thousand clients, it'd be much more optimal to
register the read event once (~EV_ONESHOT) then have the application
call back when it's no longer interested in the read events.
The same could be said for EV_WRITE events, for streaming applications
you don't want EV_ONESHOT because as soon as the event fires you're
most likely going to blast the pipe full then request notification
when more space is available. The only time you'd want the event
cleared is when you're out of data and the socket isn't full.
Perhaps for EV_WRITE/EV_READ a hints based mechanism could be used
to specify whether interest will most likely remain for the event
asked for.
--
-Alfred Perlstein - [alfred@freebsd.org]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010425134902.S1790>