Re: kern/58916: timerfd(2) claims ready for write

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 19 Dec 2024 02:39:17 +0000
    From:        Taylor R Campbell <campbell%mumble.net@localhost>
    Message-ID:  <20241219023918.2023460BB5%jupiter.mumble.net@localhost>

  | select(2) returns nonwritable if asked about the reader side of a
  | pipe (and vice versa, nonreadable if asked about the writer side of a
  | pipe).  Is that a bug?

Perhaps - I assume that also applies to any fd open O_WRONLY or O_RDONLY
with select/poll used for the other direction.   In practice I'm not
sure it matters, as real code just doesn't do things like this, code
doesn't ask when it can write to a fd which doesn't support write()
there's no point.

  | (This came up in Python's automatic tests of select on timerfds,

Yes, I saw that -- the number of issues made that look more like
an "is this linux" test, that kind of thing is also likely the
only place where this difference would be noted, and even then I
don't see the point, after all we could extend the timerfd interface
to make writing have some meaning (no, I have no idea what that
might be) - unless they actually intend writing to it in real
applications, testing that it must fail (at all, just just via
select/poll) seems like a pointless waste of time, it isn't as
if this is a specific test of just that interface even.

  | Happy to revert the change.

No need, like I said initially, I don't really care what the
behaviour is here.   I just like to make sure we don't fall
into the trap of "select() (or poll()) said it was writable,
so a write must succeed!" mentality.

kre