Re: hurd/term users.c

[Roland McGrath]

> Well, the Linux manpage on my Debian system for select has:

Point one: Linux manpage.  Ha.  Ha ha.

>        EBADF  An  invalid file descriptor was given in one of the
>               sets.
> 
> I interpreted that to include both a totally bogus number as well as
> one being used inappropriately.  

I don't think that is what "invalid file descriptor" means in anything I
have read.  That is, things often say e.g. "an invalid file descriptor or a
file descriptor not opened for reading".  I have always interpreted
"invalid file descriptor" to mean an integer that does not have a live
entry in the descriptor table (i.e. unused slots, values higher than the
table size limit, and negative integers).

> Linux pipe code, for example, will let you have a pipe open only for
> writing, and still poll on read for that pipe, AFAICT.  That's so
> totally wrong; we should not duplicate that.  
> 
> So I don't mind replacing such errors with "no response" results; but
> I strongly object to letting people getting poll results for read (or
> write) on an fd that they don't have open for reading (or writing).
> Replacing the error case with a "just return no" case is fine by me,
> but don't just elide the check entirely.

I take it the behavior you don't like is for a blocking select or poll to
to actually block waiting for an impossible condition that can never come
true.  From reading kernel source (and not having experimented), that
appears to be what Linux does in the case where the only types requested
are those that will never be available.  (This behavior is implemented in
generic code, and is not specific to pipes.)  Also from inspection alone, I
think that is exactly the same behavior FreeBSD has (the poll/select
implementation structure is similar).

I don't really think this is a totally unreasonable behavior.  I mean, the
semantics are "wait until this fd is readable", and if the fd is not opened
for reading that event will simply never happen.  OTOH, if you state the
semantics as "wait until a `read' call made on this fd will return quickly",
then it is always the case that a read call would return quickly with EBADF.

To be consistent with the latter of those two logics, the polling for both
read and write on a descriptor opened for only writing should return
immediately indicating readability since read will quickly return EBADF.
But even your term code before I changed it did not behave that way.

Furthermore, your term code has the very behavior you just decried (and my
change does not affect this).  Requesting SELECT_READ on a descriptor
opened only for writing will block forever.

The change I've made makes the treatment of SELECT_URG on a descriptor
where it's meaningless (i.e. a tty) inconsistent with that, in fact.  To be
consistent, term's io_select would just ignore SELECT_URG altogether,
whereas with my recent change it returns an immediate "nothing available"
answer if the request was for SELECT_URG and nothing else.  

I think that in fact I should change it again, so the behavior is consistent.
Then it will be the same as I've described above that Linux and FreeBSD do.

I can't see any argument based on consistency that's in favor of treating
the case where the request was solely for an impossible condition
differently from the case of a request for both possible and impossible
conditions.  A consistent argument would require that e.g. requesting more
than one type on a descriptor incapable of delivering all three always
return immediate readiness for the impossible types.

We already know of at least one example of a real-world user program that
uses select by putting all its fds of whatever flavor into all three
fd_sets, and expects select to wake up only when there is something useful
to do.  I suspect that model of operation works correctly on every other
system out there.  So you will have a hard time making the case for
breaking this assumption.