From owner-freebsd-hackers  Fri Nov 15 15:23:04 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA25859
          for hackers-outgoing; Fri, 15 Nov 1996 15:23:04 -0800 (PST)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA25850
          for <hackers@freebsd.org>; Fri, 15 Nov 1996 15:23:01 -0800 (PST)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA29400; Fri, 15 Nov 1996 17:06:28 -0600
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199611152306.RAA29400@brasil.moneng.mei.com>
Subject: Re: Sockets question...
To: terry@lambert.org (Terry Lambert)
Date: Fri, 15 Nov 1996 17:06:28 -0600 (CST)
Cc: jgreco@brasil.moneng.mei.com, fenner@parc.xerox.com, hackers@freebsd.org
In-Reply-To: <199611152204.PAA27125@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 03:04:32 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Ummm... and the problem is...?
> > 
> > As far as I am aware, byte oriented data can be written to unaligned
> > addresses on any UNIX architecture that I have seen.
> 
> It's not efficient.  It may take multiple bus cycles each time you
> break for more data making it not-as-fast-as-it-could-be.  It is ugly
> and inelegant.  It offends our aesthetics.

Tough doodles.  It is a fact of life.  However, as it is the unusual case,
it is probably not a real big performance deal.

> > xread is explicitly called with what is clearly a byte oriented buffer.
> 
> You could make the same arguments about bcopy, but we've optimized
> it for alignment boundries anyway.

Yeah... which has what to do with what?

> > If you are possibly worried about something such as the atomicity of
> > reads (potentially valid in a threaded environment, or one using shared
> > memory), I agree that there may be some concern.  Since it is not clear
> > to _me_ that such atomicity of access would be valid under the same
> > circumstances even with read(), I would probably code around the
> > situation anyways.
> > 
> > Is there some other problem that I am missing?  I've done this sort of
> > things for several years now...
> 
> Non-shared memory, but using a mmap'ed region as the destination buffer.
> In this case, I want to validate the target address range once and
> copy direct out of the frag buffers into the user buffer.

And you can't, because you may have to perform multiple read() calls,
is that your objection?  I guess I don't really see how that is a
major earth shaking crisis.

Well, fine, go fix it.  While you are at it, break FreeBSD's BSD
compatibility.

> I can make similar arguments about write's of a mmap'ed region.
> 
> I believe that an FTP server sending files to a client would qualify,
> after the initial descriptor header is sent, and the only thing left
> to send is the file data.

Yes.  So use a blocking socket, and arrange not to be disturbed by signals,
and I think you are probably in pretty good shape.

> Further, if tthe kernel detected this happening, it could asynchronusly
> complete, and delay the unmapping until the transmit was complete,
> tunring almost the entire transaction around in kernel space.
> 
> The same thing goes for whole file downloads (ie: .EXE, .DLL, etc.)
> for DOS clients of a UNIX server.

Point being?

... JG