hp-ux 7.0/800 select() strangeness?

[Chris Hanson]

   From: eliot at dg-rtp.dg.com (Topher Eliot)
   Date: 6 Sep 90 17:21:44 GMT

   |> This `select' call was returning with a single bit set, which
   |> indicated that the input file descriptor from one of the dead
   |> subprocesses had some input that could be read.  Emacs then dutifully
		   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |> went into a `read' call on that descriptor, which fortunately was set
   |> to non-blocking mode, and the `read' call returned saying that of
   |> course there was no data.
   |> 
   |> In summary: we have two processes and a pipe from one to the other.
   |> The read side of the pipe has been set to non-blocking mode by the use
   |> of O_NONBLOCK.  The process on the write side of the pipe finishes by
	 ^^^^^^^^^^
   |> calling `exit'.  The process on the read side receives SIGCHLD and
   |> uses `waitpid' to extract the exit status of the now-dead subprocess.
   |> It then does a `select' on the read side of the pipe, which returns
   |> indicating that the pipe has some data to be read.  The process calls
   |> `read' on the pipe, which returns zero indicating no data is
   |> available.  Etc.
   |> 
   |> Now I'm no expert, but it's my belief that `select' shouldn't indicate
   |> that the pipe has input in this situation.

   Well, in fact, it isn't.

   I've bumped into this problem before, in a different context.  I can't
   remember what any of the applicable documentation said, but the bottom line
   was that the semantics of select are that it will return with a particular
   bit set if a read on the corresponding file descriptor WILL NOT BLOCK.  It
   is NOT saying that there is data to be read there.  In my opinion, in such
   cases the correct way to handle this is that all reads should be prepared
   to detect that the descriptor from which they are reading has been closed,
   or reached end of file, or whatever, and handle that appropriately.
   Apparantly emacs does not do so in this case.

Since I posted the original message, I've changed my mind.  The only
thing I now believe about `select' is that it should return a
"readable" bit when there is data to be read from that channel.  I
have no opinion about what it should do in any other case.

The real problem here is that the documentation for `select' doesn't
define what it does.  The documentation defines the results as "ready
for reading, writing, or has an exceptional condition", but fails to
say what that means.  For example, I spoke to an HP engineer recently
who had no idea what an "exceptional condition" is in this context.
And I have no idea what it means either -- despite the fact that I'm
quite knowledgeable about unix.

Please, HP documenters, rewrite this man page so that it is possible
for us to know what it means!  It's no excuse that every other unix
says the same thing.

An aside: if it were the case that "ready for reading" meant "a read
on this channel will not block", then `select' would always say
"readable" for every non-blocking channel.  But emacs did a `select'
on four channels, all non-blocking, and it indicated only one of them
was "readable".  So I don't believe this definition is correct.

To paraphrase what I said above, I dunno what to believe.

In any case, emacs is now fixed so that it doesn't care what `select'
says in this case.