Return to BSD News archive
Xref: sserve comp.unix.misc:10579 comp.unix.pc-clone.32bit:5172 comp.unix.bsd:13117 comp.windows.x.i386unix:5915 biz.sco.general:9466
Newsgroups: comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.bsd,comp.windows.x.i386unix,biz.sco.general
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!ftpbox!mothost!binford!laidbak!stevea
From: stevea@lachman.com (Steve Alexander)
Subject: Re: SCO market share
Message-ID: <1993Dec18.215841.28755@i88.isc.com>
Sender: usenet@i88.isc.com (Usenet News)
Nntp-Posting-Host: ozzy.i88.isc.com
Organization: Lachman Technology, Inc., Naperville, IL
References: <2elv4l$7bf@panix.com> <2em4ds$n22@vanbc.wimsey.com> <2eocag$ce1@u.cc.utah.edu>
Date: Sat, 18 Dec 1993 21:58:41 GMT
Lines: 25
In article <2eocag$ce1@u.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>(1) The remote side closes the fd, the local write fails with -1
> and the streams context for the fd is destroyed.
>
>(2) A subsequent second operation (in this case a read) on the
> invalid fd does not return an error (per the documentation);
> instead the process is kicked as if it called exit(2).
>
The process exits because it gets a SIGPIPE if a write or send fails on
a socket. As far as I can determine (including writing a test client/server),
this behavior is compatible with BSD 4.4 and SunOS 4.1.3.
There was a bug where with SS_CANTSENDMORE handling that could screw up
datagram sockets and cause spurious SIGPIPE generation in certain
circumstances, but this has been fixed for years.
>([select] being implemented in the library using poll doesn't
>help, either)
I don't understand this comment, since select is a system call in SCO UNIX.
--
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574 | ...!{sun,ico}!laidbak!stevea