Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site hp-pcd.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!hp-pcd!hp-dcd!donn From: donn@hp-dcd.UUCP Newsgroups: net.unix-wizards Subject: Pipe/FIFO + NDELAY question - (nf) Message-ID: <1279@hp-pcd.UUCP> Date: Mon, 4-Jul-83 03:24:22 EDT Article-I.D.: hp-pcd.1279 Posted: Mon Jul 4 03:24:22 1983 Date-Received: Wed, 6-Jul-83 15:45:13 EDT Sender: netnews@hp-pcd.UUCP Organization: Hewlett-Packard, Corvallis OR Lines: 45 #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