Pipe/FIFO + NDELAY question - (nf)

[donn at hp-dcd.UUCP]

#N:hp-dcd:3200002:000:1922
hp-dcd!donn    Jul  2 09:58:00 1983

I've run into something in System III that I don't fully understand
and would like opinions on.

Consider a pipe (or FIFO) with the O_NDELAY flag set.  The pipe is
(statically) nearly full (say it can contain 6 more bytes).  If
I do a write of 10 bytes, the write returns zero, as the manual says
it should.  If, however, I do a write of PIPESIZ + 5, it will write
6 bytes and return PIPESIZ-1 as a residual count.  There is a special
case in the code so that a write of more than PIPESIZ bytes will be
partially completed in NDELAY mode.  (It will reduce the residual to
less than PIPESIZ, and then return.)  

All of this assumes that the reader of the pipe is not reading.  That
would not really change the behaviour, but would introduce timing effects.

Question: what was intended; does anyone have any guesses?  Any scenario
I come up with is a lose when dealing with NDELAY mode and long writes:

1) Leave it as is: lose 1: NDELAY will sometimes delay indefinitely,
			    depending on the consumer.  This is unexpected
			    behaviour and could cause some programs to fail
			    if the critically rely on NDELAY.
		   lose 2: The behaviour is difficult to explain to a user
			    because the form is "the write fails unless its
			    too big, then it kinda works".

2) Prohibit long writes: simply refuse to do a write longer that PIPESIZ.
   This is easy to explain, but there will be some (hopefully small) number
   of programs that will fail.  (This prohibition might only apply in NDELAY
   mode, or for consistency, independently of NDELAY, but for pipes/FIFOs
   only.)

3) Make NDELAY not work for long writes (it then acts like a 'normal'
   pipe).  This is a lose for programs that need NDELAY mode.

Personally, I like mode 2, as it is the most likely to be caught during
initial development of the program.  Have I missed something?

Donn Terry
...[ucbvax!]hplabs!hp-dcd!donn
...csu-cs!hp-dcd!donn