Xref: utzoo comp.sys.hp:6124 comp.unix.internals:177
Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!snorkelwacker!ai-lab!zurich.ai.mit.edu!cph
From: cph@zurich.ai.mit.edu (Chris Hanson)
Newsgroups: comp.sys.hp,comp.unix.internals
Subject: Re: hp-ux 7.0/800 select() strangeness?
Message-ID: <CPH.90Sep10020013@kleph.ai.mit.edu>
Date: 10 Sep 90 06:00:13 GMT
References: <90242.151955MAH@awiwuw11.wu-wien.ac.at> <CPH.90Sep9022935@kleph.ai.mit.edu> <26445@mimsy.umd.edu>
Sender: news@ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.
Lines: 44
In-reply-to: chris@mimsy.umd.edu's message of 9 Sep 90 12:53:02 GMT

In article <26445@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:

   From: chris@mimsy.umd.edu (Chris Torek)
   Date: 9 Sep 90 12:53:02 GMT

   In article <CPH.90Sep9022935@kleph.ai.mit.edu> cph@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'.

OK, now I think I understand -- thanks.  I guess my complaint is that
the man page for `select' could have contained something of what you
said in these two paragraphs.

Here is a suggestion: why not define the meaning of "readable" and
"writable" in the `select' man page, since it seems that most devices
will satisfy this definition in the same way.  Also have a sentence
that says "exceptional conditions" are device-specific, because the
current man page doesn't say anything of the kind.  Then have specific
devices document (in section 7) how their "readable" and "writable"
differ from the standard (if at all), and what their "exceptional
conditions" are.  This would be a great improvement over the current
situation, because then it would be possible to understand how this
works.