hp-ux 7.0/800 select() strangeness?

[Topher Eliot]

In article <CPH.90Sep9022935 at kleph.ai.mit.edu>, cph at zurich.ai.mit.edu (Chris Hanson) writes:
|>    From: me
|> 
|>    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.
|> 
|> 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.

Well, this shows that your kernel is different from the one I dealt with,
because with ours, select did indeed say that the descriptor was "readable"
all the time.

-- 
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.