Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!utah-cs!donn
From: donn@utah-cs.UUCP (Donn Seeley)
Newsgroups: net.unix-wizards
Subject: Re: don't do long jumps in signal handlers
Message-ID: <3255@utah-cs.UUCP>
Date: Sun, 24-Mar-85 07:09:18 EST
Article-I.D.: utah-cs.3255
Posted: Sun Mar 24 07:09:18 1985
Date-Received: Sat, 30-Mar-85 05:29:13 EST
References: <312@calgary.UUCP> <2175@wateng.UUCP> <542@utcs.UUCP> <562@astrovax.UUCP>
Organization: University of Utah CS Dept
Lines: 22


	From: wls@astrovax.UUCP (William L. Sebok)

	In my opinion, if [Berkeley] didn't want signals to abort
	terminal reads they should have provided an explicit i/o abort
	function that could be called from the signal handler.

I wrote such a function and posted it to the net some time ago...  It
was a bit ugly but it worked.

I understand that Berkeley may be considering providing a facility for
4.3 BSD that would allow you to specify that a particular signal can
interrupt a slow system call.  This might be done by changing the
on_stack member in the sigvec structure to be a generalized flags
variable, and inventing a flag that would tell the system, 'Don't
restart system calls when you see this signal.'

To quote a recent version of the signal.h file at Berkeley,

	'isn't compatibility wonderful!'?

Donn Seeley    University of Utah CS Dept    donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn