On Tue, 25 Feb 2003, Jaromir Dolecek wrote:

> So a summary:
> 1. only transfers <= PIPE_BUF are guaranteed without blocking
>    if pipe descriptor is 'writable' (as flagged by select(2))
> 2. non-blocking write(2) may return successfully with short write count,
>    or with EWOULDBLOCK error
>

I know all this, but why is PIPE_BUF 512 bytes on NetBSD. Hysterical
raisins? If fewer (misguidedly non-portable) applications fail with a
PIPE_BUF of 4K, and if the larger PIPE_BUF has no negative performance
implications and perhaps even improves performance, then it seems to me
that PIPE_BUF should be raised.

I am not arguing that NetBSD has a bug, Postfix had the bug in assuming
that 4K writes to writable pipes will not block. The assumption was true
on most systems including the decidedly BSDish SunOS 4.x (at its time the
most popular BSD derived platform).

The question is not whether PIPE_BUF == 512 is correct, but rather whether
it is wise? Is inertia the reason to keep it at 512, or is there a
reasonable guess that something might break if it is raised (that code
must also be buggy, no?), or is there some other rationalle.

-- 
	Viktor.