From owner-freebsd-hackers  Tue May 27 14:25:39 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA04590
          for hackers-outgoing; Tue, 27 May 1997 14:25:39 -0700 (PDT)
Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA04584
          for <FreeBSD-Hackers@freebsd.org>; Tue, 27 May 1997 14:25:36 -0700 (PDT)
Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20])
	by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id NAA16479
	for <FreeBSD-Hackers@FreeBSD.ORG>; Tue, 27 May 1997 13:53:25 -0700 (PDT)
Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.AB958F80@mailer.syr.edu>; Tue, 27 May 1997 16:47:31 -0400
Received: from localhost (cmsedore@localhost)
	by rodan.syr.edu (8.8.5/8.8.5) with SMTP id QAA15888;
	Tue, 27 May 1997 16:47:22 -0400 (EDT)
X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs
Date: Tue, 27 May 1997 16:47:22 -0400 (EDT)
From: Christopher Sedore <cmsedore@mailbox.syr.edu>
X-Sender: cmsedore@rodan.syr.edu
To: "Ron G. Minnich" <rminnich@Sarnoff.COM>
cc: FreeBSD-Hackers@freebsd.org
Subject: Re: async socket stuff
In-Reply-To: <Pine.SUN.3.91.970527141129.23490O-100000@terra>
Message-ID: <Pine.SOL.3.95.970527163325.11761A-100000@rodan.syr.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk



On Tue, 27 May 1997, Ron G. Minnich wrote:

> > It sure could, but you end up with many more system calls, and it is not
> > async.  The real advantage to a call like TransmitFile() is that you can
> > send an entire file (or a range of a file) with a single system call, and
> > you can do it async.  This means that you can more efficiently implement
>                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > things like FTP servers, Web servers, pop servers, etc.
> 
> And the measurements which show this are to be found ... where? I'm not 
> convinced. You've got to pay the cost for this somewhere. 
> "complexity is conserved" -- D. Jensen

Well, you can do some math which might demonstrate it:

To transfer a 10MB file now, you might implement something like:

open(...)

while (!eof) {
  read(file,buf,64k)
  write(sock,buf,64k)
}

close(file)

with a transmitfile-like facility, you would:

open(...)
transmitfile(file,sock,...)
close(file)

Now, in the case of a 10MB file, you've essentially saved 20MB worth of
memory bandwidth/time for transfer (since the data has to be copied into
user space on read, and back again on write), plus 160*2=320-1=319 system
calls avoided.

I do acknowledge that you could of course do:

open(...)
mmap(...)
write(...)
munmap(...)
close(...)

but this has another set of efficiency concerns with setting up the map. 
I think you still end up with a user to kernel copy you might otherwise
avoid (corrections welcome).  You also have restrictions on how much space
you can map into a process (a problem I currently experience with an NT
app which hangs around 1.5GB of reserved address space with a 2GB
OS limit).

What's the cost?  another few hundred bytes of kernel code.  Worth it to
me, esp since it would probably be duplicated many times over in
user code.

-Chris