Questions about read() and write()

[Chris Torek]

> ... what happens to the current file position if a read() or write()
> is interrupted?  This is another non-documented issue, near as I can
> tell.  Should another lseek() be issued when restarting one of these
> calls (when dealing with disk files)?

read() and write() on disk files cannot be interrupted: the entire
transfer will happen before a signal is taken.  This ought to be true
even in System N.

You might lose the return value if a signal arrives "inside" a disk
read() or write().  Other than that, everything should be OK; the
current position will be after the read/written bytes.

> What happens if, under 4.2, an alarm call causes the read() or write() to
> be restarted for me (is there a good reason why this was changed in 4.2)?

The alarm will interrupt a read() or write() of a ``slow device'' (e.g.,
terminal; technically, anything that sleep()s at > PZERO).  After the
alarm handler returns, the system call will continue wherever it left
off, and will pretend it was never interrupted at all.  Thus you won't
lose the return value, or anything else nasty.  This is only true in 4.2
(and 4.1 when using -ljobs).
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland