Re: two pipe bugfixes

[Linus Torvalds]

On Mon, 28 Feb 2005, Andrea Arcangeli wrote:
> 
> > [..] And python-twisted is just plain bogus.
> 
> What do you mean with this, could you elaborate? You mean it shouldn't
> check for in/out set at the same time? I've no idea why it got confused
> by out/in set at the same time, but I guess it could be some
> compatibility thing with some other os.

I wonder. It migth just be a latent bug in python-twisted, rather than any 
"designed behaviour".

> Still my point is that such code should never trigger since pollin
> should never be set for an output-pipe-fd.

Equally arguably, POLLERR should _always_ be set if you select a
write-only pipe for reading, and guess what? That would cause "select()"
to return readable. It's true too: select returns whether a read() would
return immediately, and it _would_ - with an error code.

The basic fact is that an application that asks whether the pipe that it
opened for writing is readable is doing something stupid, and the old
behaviour was at most surprising, but I'd argue it isn't really
necessarily a _bug_.

Of course, "surprising" is bad, even if it's not necessarily a bug. So 
making the return value be "unsurprising" can in any case be considered an 
improvement.

> > I don't agree with your patch, though - I don't like your lack of
> > parenthesis ;)
> 
> ;)

I ended up editing it a bit more: the other bits (POLLHUP and POLLERR)  
also really only make sense for only one side of the reader/writer
schenario, so logically they should be grouped the same way.

Of course, in those cases, you can't get the "wrong" answer anyway, since
those only trigger if there are no readers or no writers (and if you're
open as a reader, that in itself obviously guarantees that there _are_
readers, and POLLERR cannot happen according to either the old or the new
rules).

Anyway, I think I made the code look more logical while there.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/