Xref: utzoo comp.sys.hp:6143 comp.unix.internals:207 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!mcnc!rti!dg-rtp!chutney!eliot From: eliot@chutney.rtp.dg.com (Topher Eliot) Newsgroups: comp.sys.hp,comp.unix.internals Subject: Re: hp-ux 7.0/800 select() strangeness? Message-ID: <1990Sep11.151702.28490@dg-rtp.dg.com> Date: 11 Sep 90 15:17:02 GMT References: <90242.151955MAH@awiwuw11.wu-wien.ac.at> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: eliot@dg-rtp.dg.com Organization: Data General Corporation, Research Triangle Park, NC Lines: 29 In article , cph@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@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.