On Wed, 26 Feb 2003, David Laight wrote:

> Does Posix say that?
> I didn't see any refererence to PIPE_MAX in the posix select man page.

Posix does not say it explicitly, but it does if you read "between the
lines", since writes of PIPE_BUF bytes are atomic with pipes, and since a
writable pipe should absorb *some* output when a non-blocking writer
writes to it (the sender should not see EWOULDBLOCK), a writable pipe must
have at least PIPE_BUF bytes free. Otherwise a non-blocking writer would
wake up in a tight loop waiting for PIPE_BUF bytes to become available.

So POSIX does not need to spell out the implications for poll()/select(),
they follow from what is already said.

>
> In any case it definitely says that a write of more that PIPE_MAX
> can return having put less that PIPE_MAX bytes into the pipe.
> (indeed a test suite may decide to test for such behaviour, and
> (I think) assume that reading a byte implies that a byte can be written).
>

If you find a pipe implementation that selects writable with less that
PIPE_BUF bytes free, it is broken. I don't expect that the NetBSD
implementation is among these.

In any case no one has actually addressed my main question, setting aside
lectures on how to write applications, how big should PIPE_BUF be to
provide POSIX compliance, near optimal performance and maximal application
portability. My vote if anyone is willing to listen (no pun) is 4K, as I
would argue that 512 may wake up the writer *too often*, and increases the
likelihood of problems due to interleaving of writes, also somewhat broken
applications like Postfix <= 2.0.3 that empirically found that 4K works on
other systems, would also work on NetBSD. And while one can be proud that
one's operating system breaks sloppy applications, in practice being more
forgiving has better evolutionary properties...

Over and out. I think I have made my point. I like NetBSD, I am not
attacking it, I like Postfix, I am not defending it. I have learned
something from how the two interact, and perhaps my experience is useful
to the community, even if the benefit is only to reinforce the view
that the current implementation is on closer inspection just right.

-- 
	Viktor.