Viktor Dukhovni wrote:
> 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.

PIPE_BUF value doesn't have any influence on pipe performance.
Kernel doesn't use the value, only to check 'writability' of the
pipe descriptor for select(2). For example, if blocking write is
called for pipe with data buffer of 10MB size, kernel would move data
around in quite large chunks (up to 1MB), without any regard to
PIPE_BUF value.

> 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

Neither if these.

AFAIK it's kept low precisely for the POSIX atomicity/nonblocking
requirement.

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.

> (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?

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-