I promised to not follow up to this list, but since others appear to want
to see the discussion here, I will break my promise and await
punishment...

On Tue, 25 Feb 2003, Jaromir Dolecek wrote:

> > 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
>
> There is no way to change low-watermark for pipes, there is no
> equivalent of SO_SNDLOWAT for pipes. Pipe cannot be flagged 'writable'
> before there is PIPE_BUF space in pipe buffer.  Different apps might
> have different idea of when they want to write more data to pipe.
> Keeping the writable treshold low is safe bet.
>
> Having low PIPE_BUF may actually improve data transfer speed, since
> the data exchange might be more fluent - writer gets notified early,
> reader blocks less.
>

This assumes that waiting for say 4K to be free would risk starving the
reader. I am not convinced this is true. The bulk of the clients are using
stdio and already reading and writing multiples of 4K. Yes it is possible
that the reader can drain the entire pipe and block before the writer
makes more data available, but how much more likely is this not to happen
with the smaller PIPE_BUF. If one wants to ensure that the pipe never
drains, one must raise the pipe capacity. The atomicity should have little
effect on whether the reader manages to drain the pipe.

With small PIPE_BUF one gets more opportunity for applications to block
unexpectedly, and more opportunity for unexpected interleaving of I/O
requests. Even if there is a neglibile performance gain (I would naively
the larger PIPE_BUF to be cheaper due to fewer wakeup events). I disagree
that it is a "safe bet".

> > (that code must also be buggy, no?), or is there some other rationalle.
>
> What does 'that code' refer to? NetBSD code or random application code?
>

Application code. Applications that break when PIPE_BUF is raised to 4K
from 512 are buggy (just as Postfix was, when assuming PIPE_BUF >= 4K).

-- 
	Viktor.