Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ai-lab!ai.mit.edu!sundar
From: sundar@ai.mit.edu (Sundar Narasimhan)
Newsgroups: comp.unix.programmer
Subject: Re: question about non-blocking I/O and SIGPIPE
Message-ID: <14359@life.ai.mit.edu>
Date: 25 Mar 91 21:39:48 GMT
References: <14318@life.ai.mit.edu> <27643@uflorida.cis.ufl.EDU>
Sender: news@ai.mit.edu
Reply-To: sundar@ai.mit.edu
Organization: MIT Artificial Intelligence Laboratory
Lines: 22

In article <27643@uflorida.cis.ufl.EDU>, leh@atlantis.cis.ufl.edu (Les Hill) writes:
|> In article <14318@life.ai.mit.edu>, sundar@ai.mit.edu (Sundar Narasimhan) writes:
|> |> I've read the man pages, but this info is not found anywhere. 
|> ...asks why he is dying on a SIGPIPE...
|> 
|> You may have indeed read the man pages, you did NOT read them carefully.
|> The SunOS man page for write(2v) under the ERRORS heading clearly answers your question (look at EPIPE.)
Ok. Maybe I wasn't clear enough in my message. I did read the stuff about
EPIPE but I'm trying to reconcile my understanding of EINTR/EPIPE and 
the sequence of events as they occur when you do a write(). 

Supposing you do a write(fd, buf, 20); Which of the foll. is correct?
	*  If the process on the other side dies DURING the write,
	   (i.e. say after 10 bytes were written), then write will
	   return -1 and errno will be set to EPIPE. SIGPIPE will 
	   be delivered AFTER write() returns.
	* SIGPIPE may be raised DURING the write, causing it to notice
           this, return -1 with errno set to EINTR.
	
Is it also true that with non-blocking I/O set, write returning 0 should
be handled exactly identical to the case when write returns any other
value < bc?