RE: [Fwd: Weird ia64 problem]

[Jeff Licquia <licquia@progeny.com>]

On Wed, 2005-10-05 at 16:28 -0700, Luck, Tony wrote:
> Now, the question becomes "is this a bug". As you pointed
> out in an earlier e-mail the standard makes no mention of
> what happens when you read some data from a full pipe. So
> we appear not to be in violation of the letter of the standard.
> 
> But this does fly in the face of common sense.
> 
> As you say above, reporting the PIPE_BUF value as PAGE_SIZE
> [probably max(4096, PAGE_SIZE) ... for any arch that has a
> page size smaller than 4k] would fix this.  But then we get
> back to the historical properties of 4k as the PIPE_BUF size.
> Would such a change break existing applications that are not
> well enough written to use fpathconf(fd, _PC_PIPE_BUF)?

I think there's a problem with this.  While PIPE_BUF is specified in a
kernel header, it ends up becoming an embedded value in glibc, from what
I can tell.  Which also makes it an embedded value in statically linked
apps.  This looks like a dead end, even for apps that use fpathconf().

Also, from looking at some of the kernel comments (like where PIPE_SIZE
is defined), it seems that the kernel powers-that-be also intend to keep
PIPE_BUF and PAGE_SIZE decoupled.

So the way forward seems to be to add a test to pipe_readv() for this
condition.

I'm thinking it should check if (PIPE_SIZE - buf->len) > PIPE_BUF, and
set do_wakeup.  The code could be #defined out if PIPE_SIZE = PIPE_BUF,
so the change reduces to a no-op on other archs.

Does that sound right?  I'm going to work on a patch here.