Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ecompin!netxcom!sundc!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.wizards
Subject: Re: The 4.3 BSD awrite() solution
Message-ID: <131445@sun.Eng.Sun.COM>
Date: 8 Feb 90 05:33:27 GMT
References: <1055.18:35:28@stealth.acf.nyu.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Distribution: usa
Organization: Sun Microsystems, Mountain View
Lines: 32

In article <1055.18:35:28@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
>According to the 4.3 BSD siginterrupt() documentation, after a program
>executes siginterrupt(SIGALRM,1), interrupted I/O calls will return the
>number of bytes actually read. Then the (untested) code below should
>provide a true awrite(). Any comments?
>
>---Dan
>
>[code that schedules an alarm and then starts a write deleted]

Funny you should ask.  The answer is, "no, this won't work the way you think".
Why?  Hmm.  Think of the kernel as a processor with system calls being
instructions and signals being interrupts.  In general, interrupts do not
interrupt an instruction.  That is mostly true inside the kernel as well (*).
I beleive that your code wanted to get the write rolling and then return
after it was started (this is what almost every Unix system does anyway unless
you have opened the file with O_SYNC, so this is a moot point, but...).  The
only way (*) that the signal would cause an early return is if the signal 
arrived while the write() was waiting for some resource (was sleep()ing, in
kernel sense).  Once the ``instruction'' gets rolling you can't interrupt it.

(*) An interesting exception.  Someone at Xerox pointed this out to me: if
you have a buffer, say two pages worth, with the first page R/W and the
2nd page RDONLY, and you hand that to read(), you get a SIGSEGV halfway 
through the read() and a return value of -1.  This is a bug in most current
implementations of Unix (including SunOS).  So there is a way that signals
can interrupt an ``instruction'' but you have to work hard and we'll fix it
eventually....
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.
    Besides, I frequently read news when I'm drjhgunghc, err, um, drunk.
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com