From owner-freebsd-arch Wed Apr 25 13:49: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0CAFA37B422 for ; Wed, 25 Apr 2001 13:49:07 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3PKn2301895; Wed, 25 Apr 2001 13:49:02 -0700 (PDT) Date: Wed, 25 Apr 2001 13:49:02 -0700 From: Alfred Perlstein To: "Andrew R. Reiter" Cc: freebsd-arch@FreeBSD.ORG, provos@openbsd.org Subject: Re: libevent & fbsd Message-ID: <20010425134902.S1790@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from arr@watson.org on Wed, Apr 25, 2001 at 04:26:32PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc'd Niels Provos. * Andrew R. Reiter [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