In article <1151887356.005702.1823.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi  <yamt@mwd.biglobe.ne.jp> wrote:
>> | 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.
>> 
>> What is strange to me is that now we have a situation whereby by
>> default we have select() returning that the socket is not writable,
>> but a write() to it will succeed and not block. This does not seem
>> right to me. What's worse, is that now, we'll never return that
>> the socket is writable, unless the buffer is entirely empty.
>
>writeability wrt select() is defined with sb_lowat in posix.
>
>    If a descriptor refers to a socket, the implied output function is the
>    sendmsg() function supplying an amount of normal data equal to the current
>    value of the SO_SNDLOWAT option for the socket.
>
>so it's normal for select not to consider it writable.

Totally agree, only here a socket is used to implement a named pipe,
and a named pipe is what the application sees.

>it's what i meant by "PIPE_BUF atomicity".  i don't think it's broken.

I am afraid that selecting inappropriate values for lowat/hiwat will break
that.

christos