hp-ux 7.0/800 select() strangeness?

[Chris Torek]

In article <CPH.90Sep9022935 at kleph.ai.mit.edu> cph at zurich.ai.mit.edu
(Chris Hanson) writes:
>The real problem here is that the documentation for `select' doesn't
>define what it does. ...

Well, the most likely reason is that select does not *do* ANYthing,
except time out.  The `selecting' is all done in lower layers, much
like ioctl.  There is no way that ioctl(2) can list what ioctl()
does, because it really does not do *any*thing.

>"... reading, writing, or has an exceptional condition"

Of course, the lower layers try to do something sensible.  For `read',
select is supposed to return true whenever a read() system call would
not block, regardless of any `non-blocking' mode on the file
descriptor.  That is, it should return true when there are data, and it
should return true when there is a `boundary condition' like an `EOF'
on a tty or a socket.  For `write', it is supposed to return true when
the lower layer can accept (some) more data without blocking.
`Exceptions' are left entirely up to the lower layers, and you have to
look at those (or read their manuals, provided that someone bothered to
document them properly) to find out which descriptor entities (sockets,
ptys, ttys, disks, tapes, ...) actually do something, and what, with
`exceptions'.

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

No, but it is close---closer than `there are data', at any rate.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris