From owner-freebsd-hackers  Tue May 27 13:33:39 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA02659
          for hackers-outgoing; Tue, 27 May 1997 13:33:39 -0700 (PDT)
Received: from cypher.net (black@zen.pratt.edu [205.232.115.155])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02654
          for <FreeBSD-Hackers@FreeBSD.ORG>; Tue, 27 May 1997 13:33:34 -0700 (PDT)
Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id QAA04768; Tue, 27 May 1997 16:33:04 -0400
Date: Tue, 27 May 1997 16:33:03 -0400 (EDT)
From: Ben Black <black@zen.cypher.net>
To: Christopher Sedore <cmsedore@mailbox.syr.edu>
cc: Ruslan Shevchenko <rssh@cki.ipri.kiev.ua>, FreeBSD-Hackers@FreeBSD.ORG
Subject: Re: async socket stuff
In-Reply-To: <Pine.SOL.3.95.970527144252.2510A-100000@rodan.syr.edu>
Message-ID: <Pine.LNX.3.91.970527162845.1463E-100000@zen.cypher.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> Well, you might better arrange to be amazed :)  It is an NT system call. 
> It's exact purpose is to avoid a read(file,buf)/write(sock,buf) loop with
> the associated user/system switch for each call.  Async doesn't buy you
> anything here except the ability to do it in the background. 
> 

how do you spell kludge?

> > btw, NT is probably the WORST place to look for inspiration.  just look 
> > at their TCP sequence generation algorithm.
> 
> I figure that I'll borrow good ideas from where ever they come...Nobody
> does everything "right" by universal or any given individual's standards. 
> 

no, but some places have more wrong than others.

> I'd just like to see FreeBSD add some enhancements to make it easier/more
> efficient for high load network applications (since I'm now breaking NT's

something like fbufs would be a general purpose and cleaner solution to 
the issue of high-speed IO.  the NT syscall you describe is nothing but a 
giant hairy hack.

> IP stack under load).  Threads (true threads, mind you)  would be nice,

breaking the NT tcp stack is no major accomplishment.

> but kernel based async IO and a few other goodies would make a big
> difference. 
> 

again, the kernel need not provide these facilities as long as they 
appear at user level (yes, this can be done, see www.cis.upenn.edu/~eros)

i would rather the kernel got *smaller* and *faster* than more loaded 
down with features.  how about a giant rearchitecting for FreeBSD 4.0? ;)


b3n