Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!mit-eddie!mit-vax!eagle!harpo!seismo!hao!hplabs!sri-unix!gwyn@brl-vld
From: gwyn%brl-vld@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re:  improved 4.2BSD signal(2) library routine
Message-ID: <14832@sri-arpa.UUCP>
Date: Tue, 20-Dec-83 23:43:35 EST
Article-I.D.: sri-arpa.14832
Posted: Tue Dec 20 23:43:35 1983
Date-Received: Sat, 24-Dec-83 04:39:44 EST
Lines: 42

From:      Doug Gwyn (VLD/VMB) <gwyn@brl-vld>

	Received: From Ucla-Locus.ARPA by BRL-VLD via smtp;  20 Dec 83 13:34 EST
	Date:           Tue, 20 Dec 83 09:39:00 PST
	From:           Bob English <bob@UCLA-LOCUS>
	To:             Doug Gwyn (VLD/VMB) <gwyn@brl-vld>
	Subject:        improved 4.2BSD signal(2) library routine
	In-reply-to:    Your message of Tue, 20 Dec 83 5:31:28 EST

	It seems to me that a signal that arrived just before the system call
	would cause the system call to be skipped.  In particular, system calls
	such as time (not in 4.2, I know) could return EINTR.  If the signal
	were truly interruptible, this wouldn't be a problem, but your routine
	doesn't check.  I don't,however, know of a better solution that doesn't
	involve changing the kernel (or making all your i/o's go through select???).

	The real problem is that the kernel doesn't show the user the
	true state of things: if a system call was interrupted and is
	about to be re-invoked, it should give the signal handler an
	explicit indication of it.  Otherwise you get quantum
	programming (no one knows the true state of the universe).

	--bob--

Yes, it is true that the system call pointed at by the PC may not have
been interrupted with the PC set back to deliberately restart the call.
This is a small, but finite, chance taken the way I wrote the routine.
It could be improved considerably by looking just past the CHMK for
the numeric syscall code (3 for read, and so forth), since there are
only a few syscalls that are restarted (READ/WRITE/OPEN on slow device,
WAIT when it is really waiting, IOCTL I believe).  Unfortunately, just
because one is about to execute one of these does not mean that it
would've been interruptible, so even with extra checking you cannot be
sure that EINTR is appropriate.  However, at least this would ensure
that EINTR is only returned from the TYPES of syscalls that one expects.

You are correct in observing that what is really needed is a way to
tell for sure that one is about to restart the syscall upon return from
the user interrupt handler.  I browsed through the 4.2BSD kernel
sources for quite a while but I did not succeed in finding a sure-fire
solution that did not involve modifying the kernel.  I would be happy
to hear of a reasonably efficient method (no, I cannot read /dev/mem).