hp-ux 7.0/800 select() strangeness?

[Topher Eliot]

|>    It seems that programs which have select(2) in their inner loop sometimes
|>    start using enormous amounts of system cpu time, just as if the select()
|>    call would return immediately as if it were polling. Among those programs
|>    are Xemacs 18.55, Greg Minshall's tn3270, and named4.8.3.
|> 
|> 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.

--
Topher Eliot
Data General Corporation                eliot at dg-rtp.dg.com
62 T. W. Alexander Drive                {backbone}!mcnc!rti!dg-rtp!eliot
Research Triangle Park, NC 27709        (919) 248-6371
Obviously, I speak for myself, not for DG.