wls@astrovax.UUCP (William L. Sebok) (03/23/85)
> I think the real problem is that UNIX allows one to catch signals at all. > Given that we don't have cheap processes a la Thoth, catching signals is a > necessary evil but signal handlers should be kept simple and in particular > should avoid using longjmp (if you have ever read and understood the source, > you won't want to use longjmp). Unfortunately if you wan't to interrupt a 4.2 read() from a terminal you have to do longjmp (or worse). In my opinion, if they 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. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
donn@utah-cs.UUCP (Donn Seeley) (03/24/85)
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