> | > Another way to "fix" the problem is to increase the high watermark
> | > if not set to be lowat + MCLBYTES.
> | > 
> | > christos
> | 
> | why MCLBYTES?
> | 
> | i don't want to tweak kernel for a configure script.
> | is there any other application which is known to have a problem?
> | 
> | YAMAMOTO Takashi
> 
> I don't know if there are any other applications, but it seems strange
> to have in the default configuration lowat == hiwat. Is the soreadable
> and sowritable macro doing the right thing in that case?

maybe it depends on the definition of the right thing. :-)
(apparently the configure script doesn't think it the right thing.)
to me, it doesn't seem so strange.

"+ MCLBYTES" in your suggestion seems rather strange to me.
i don't understand why MCLBYTES is used here.
for the configure script in question, 4 is enough.
as i'm not aware of any other affected application,
i'm not sure how many bytes are expected.
if you want to keep current (hiwat - lowat), it's
MAX(0, PIPSIZ - MCLBYTES), not MCLBYTES.

> It could also be a POSIX violation, because we are using sockets
> internally to implement pipes, there is expected behavior for pipes
> and operations < PIPE_BUF.
> 
> christos

i think <= PIPE_BUF writes are atomic as far as lowat >= PIPE_BUF.
i'm not aware of any posix pipe buffer requirements other than
PIPE_BUF atomicity.

YAMAMOTO Takashi