> From: Garance A Drosihn <dro...@rpi.edu>
> Date: 1999-09-09 10:33:59 -0700
> To: jus...@apple.com, freebsd-hackers@FreeBSD.ORG
> Subject: Re: message queues for I/O (usenix paper)
> In-reply-to: <199909090144.saa02...@rhapture.apple.com>
> X-Sender: dro...@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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to