Subject: Re: Tapeboot problem SOLUTION
To: None <port-sun3@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: port-sun3
Date: 12/12/1995 11:26:51
> Well, we don't have to argue about this for SunOS-4 or 4.4BSD
> derivatives such as NetBSD, since pipes are implemented as socket
> pairs and the manual pages for write(2) and pipe(2) do seem to make
> guarantees about this.

I just read the SunOS 4.1.3 manpages for pipe(2) and write(2) and can't
see where.  They appear to promise that {PIPE_BUF} bytes of buffering
are available, but I can't see any promise that, for example, if all
write and read attempts are in multiples of 512 bytes, then each read
will return a multiple of 512 bytes (this is, essentially, what's at
issue here).  Even if {PIPE_BUF} is a multiple of 512.

> However I would like to point out that UNIX v10 guarantees that
> writes of the appropriately small enough number of bytes to a pipe
> "are contiguous even if many processes are writing"

I think all Unices have done this, though most don't actually document
the promise, and I don't know of any that give any number for
"appropriately small enough number of bytes".

> "Writes introduce a record structure: a read will not return bytes
> from more than one write; see read(2)."

That's a bizarre change in semantics.  Consider

	( echo foo ; echo bar ) | ( sleep 5 ; cat )

The semantics you quote imply that cat will do three reads, the first
two getting 4 bytes each and the last showing EOF.  This is distinctly
nontraditional behavior, and in fact neither SunOS 4.1.3 nor
NetBSD/sparc (as of sup about a week ago) works this way; they both
have cat doing a single 8-byte read and then a read showing EOF.  Of
course, programs written for the traditional model will still work
using the model you quote, unless zero-byte writes produce zero-byte
reads, in which case readers can get EOF when there really is more to
be read.

> Indeed the SysV manuals don't make this promise, nor does it seem to
> be so according to Bach or Stevens in "UNIX Network Programming", but
> I can say that from past experience this record structure is indeed
> there.

On v10, or on "traditional" systems?  What sort of thing are you
thinking of when you say the record structure is indeed there?  I'm
quite curious.

Maybe this should move to tech-kern?  It's really getting a bit
off-topic for port-sun3.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu