Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals Subject: Re: pty bugs & features Message-ID: Date: 3 Sep 90 17:28:30 GMT References: <3948@auspex.auspex.com> <6038@muffin.cme.nist.gov> <13650@smoke.BRL.MIL> <1990Aug29.153306.18173@chinet.chi.il.us> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 49 In-reply-to: les@chinet.chi.il.us's message of 29 Aug 90 15:33:06 GMT On 29 Aug 90 15:33:06 GMT, les@chinet.chi.il.us (Leslie Mikesell) said: les> In article <13650@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) les> writes: gwyn> In article <6038@muffin.cme.nist.gov> libes@cme.nist.gov (Don gwyn> Libes) writes: libes> Why do pty's return EIO instead of 0 upon EOF? gwyn> If they do this, it is clearly wrong and would most likely be due to gwyn> UNIX development now being done, or at least directed, by people who gwyn> don't understand UNIX. read() should not return -1 upon encountering gwyn> normal EOF on ANY object. les> Is this meant to imply that the developers of STREAMS don't understand les> unix? As I understand it, several people have a grudge against USG/USO for taking the research streams and hacking them (mostly disagreeably). les> A read on a STREAMS file is documented to return -1 when O_NDELAY les> is set and there is no data available (which has unfortunately been les> propagated into the tty emulation of at least some network les> implimentations). Apparently there is some reason to want to know les> about zero length messages. Yes, *if you do messages*. Unfortunately all of UNIX is based, right or wrong, on the idea that the fundamental abstraction is a byte stream, not a message/record stream. The UNIX philosophy is that if you want boundaries you use an higher level protocol (prefix each messages/record by its length, out-of-band record boundaries, whatever). I actually prefer discrete packets (that can be typed) to virtual circuits (which are untyped byte streams) as fundamental IPC abstraction, but after all you can always build one from the other. Reread how Rochking ("Advanced Unix programming") discusses the various IPC possibilities under various Unixes, concludes that named pipes are the right thing, and then proceeds to implement records/messages on top of named pipes. Originally streams were essentially named pipes with dynamically selectable line disciplines. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk