From owner-freebsd-arch Wed Apr 25 14:14:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by hub.freebsd.org (Postfix) with ESMTP id 84C3437B43F for ; Wed, 25 Apr 2001 14:14:27 -0700 (PDT) (envelope-from provos@citi.umich.edu) Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 05BC4207C1; Wed, 25 Apr 2001 17:14:27 -0400 (EDT) Subject: Re: libevent & fbsd From: Niels Provos In-Reply-To: Alfred Perlstein, Wed, 25 Apr 2001 13:49:02 PDT To: Alfred Perlstein Cc: "Andrew R. Reiter" , freebsd-arch@FreeBSD.ORG Date: Wed, 25 Apr 2001 17:14:26 -0400 Message-Id: <20010425211427.05BC4207C1@citi.umich.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010425134902.S1790@fw.wintelcom.net>, Alfred Perlstein writes: >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. I am aware of this problem. My goal was to create a very easy to use and intuitive API that would abstract away complexities that people are experiencing with asynchronous I/O. If you have an idea to extend the API in a simple way that would make better use of the capabilities of kqueue-like systems, please let me know. I know of people who use libevent in a commercial environment, and they are very happy with it. Greetings, Niels. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message