From owner-freebsd-hackers Thu Sep 9 10:55: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id A60BD14BEF for ; Thu, 9 Sep 1999 10:54:55 -0700 (PDT) (envelope-from justin@rhapture.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id KAA23262 for ; Thu, 9 Sep 1999 10:53:55 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 09 Sep 1999 10:53:59 -0700 Received: from rhapture.apple.com (rhapture.apple.com [17.202.40.59]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA24389 for ; Thu, 9 Sep 1999 10:53:59 -0700 (PDT) Received: (from justin@localhost) by rhapture.apple.com (8.9.1/8.9.1) id KAA00820 for freebsd-hackers@FreeBSD.ORG; Thu, 9 Sep 1999 10:53:58 -0700 (PDT) Message-Id: <199909091753.KAA00820@rhapture.apple.com> To: freebsd-hackers@freebsd.org Subject: Re: message queues for I/O (usenix paper) In-Reply-To: <199909090144.SAA02454@rhapture.apple.com> Date: Thu, 9 Sep 1999 10:53:57 -0700 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: by Apple MailViewer (2.105.dev) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Garance A Drosihn > Date: 1999-09-09 10:33:59 -0700 > To: justin@apple.com, freebsd-hackers@FreeBSD.ORG > Subject: Re: message queues for I/O (usenix paper) > In-reply-to: <199909090144.SAA02454@rhapture.apple.com> > X-Sender: drosih@mail.rpi.edu > > At 6:44 PM -0700 9/8/99, Justin C. Walker wrote: > >From the FWIW department, we have, in the Darwin source, an > >implementation of a "select replacement" that is designed to get > >around some of the (perceived or real) issues with select(), e.g., > >looking at a long (FD_SETSIZE or larger) array of bits several > >times in the kernel and in user space. > > > >In the available sources, this is represented in sys/ev.h, and is > >implemented only for sockets. Our tests indicate a roughly 5-10% > >speed improvement when a lot of sockets are in use but not > >exuberantly so. > > This sounds like it will be interesting. If this works out, would > it translate to the other *BSD's fairly easily? When you say > "select replacement", do you mean select disappears from the system, > or just that this will be an alternative to using select? We didn't do much to the existing code except to add the system calls, update some structures (proc and socket) with event record queues, and add the calls to do the work whereever an event was noticed. As long as other BSDs haven't changed these areas significantly, there should be little problem (it sez here...). One note: in order to make this fast, and to avoid resource problems during use, the event records are not dynamically allocated, and there's only one per event source. These are dynamically updated when on a queue, so you don't end up with allocation failures or really long queues. As for 'select()', we'd have to be crazy (:-}) to eliminate that call. After all, we want folks to port code into our system with relative ease. The call remains; the event scheme is an alternative for those that want to use it. Its use is intended to match that of select(), so that developers don't have to restructure existing code to use it. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message