From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from doolittle.vetsci.su.OZ.AU ([129.78.148.2]) by archone.tamu.edu with SMTP id <45324>; Tue, 7 Apr 1992 20:58:54 -0500 Received: by doolittle.vetsci.su.oz.au id <49182>; Wed, 8 Apr 1992 11:55:45 +1000 From: John (Convulsed into oblivion from laughter or from fright) Mackin Date: Tue, 7 Apr 1992 20:37:36 -0500 To: The rc Mailing List Subject: Re: signal blocking? In-Reply-To: <9204072118.AA00942@terminus.cc.gatech.edu> Message-ID: <199204081137.11799.rc.baguv@vetsci.su.oz.au> References: <91Dec18.230318cst.18887@archone.tamu.edu> <199201222335.28010.rc.badaj@vetsci.su.oz.au> <92Jan28.114835cst.18891@archone.tamu.edu> X-Face: 39seV7n\`#asqOFdx#oj/Uz*lseO_1n9n7rQS;~ve\e`&Z},nU1+>0X^>mg&M.^X$[ez>{F k5[Ah<7xBWF-@-ru?& @4K4-b`ydd^`(n%Z{ Arnold asked: Is there an easy way to block a signal inside a signal handler? Without in any way endorsing the use it's proposed to put this facility to, I'd like to point out, firstly, that I don't believe there is anything substantially easier or cleaner that what you already did (although the first quote from Byron below shows an elegant twist), and secondly, that rc should block them for you. I don't know how `real' Byron will think this application is; what about it, Byron? The remainder of this message is quoted from three mail items: from Byron to me, my reply, and his reply to that. OK, John. From: Byron Rakitzis Date: Thu, 19 Dec 1991 16:03:06 +1100 To: john@vetsci.su.oz.au Subject: Re: editable terminal for X Message-Id: <91Dec18.230318cst.18887@archone.tamu.edu> [...] I am not sure what to do about high-level [signal] semantics, though. What if you get an interrupt inside a user-defined interrupt handler? I am assuming that an rc user will have to explicitly mask interrupts with something like: fn sigint savesigint { fn sigint ... code ... eval `{whatis savesigint | sed 's/fn /fn sigint/'} } Does that look reasonable? (I just came up with that solution by the way; I haven't thought about the high-level stuff much) What are the other alternatives? I have never used signal handlers in a shell for anything "real" so I cannot imagine a "real" use for them where it would matter one way or another whether signals are trapped inside them. [...] From: John (I've got some bad news for you, sunshine) Mackin Date: Wed, 22 Jan 1992 23:35:55 +1100 To: Byron Rakitzis Subject: high-level signal semantics (was Re: editable terminal for X) Message-ID: <199201222335.28010.rc.badaj@vetsci.su.oz.au> [...] Does that look reasonable? [...] It actually doesn't look that reasonable to me. I don't use signal handlers for anything `real' ever if I can avoid it, but I think that the above is not the way to go. That's giving the handlers semantics rather like those of Seventh Edition signals. Now, most things about Seventh Edition are just right, but in fact one way BSD did better is (in some facets) with signals. We are much better off with BSD signal semantics at the high (user handler function) level. They are that the handler for signal S will never be called recursively by the signal mechanism. So in the above, once you're inside fn sigint, a further interrupt will be queued and result in fn sigint being called again only after it returns. Signal S' in no way affects signal S: different signals should interrupt each other's handlers, it is only that the _same_ signal should never interrupt its _own_ handler. Those are definitely the best semantics for signal handlers to have. OK, John. From: Byron Rakitzis Date: Wed, 29 Jan 1992 04:48:34 +1100 To: john@vetsci.su.oz.au Subject: signal handlers Message-Id: <92Jan28.114835cst.18891@archone.tamu.edu> You argued for BSD signal semantics in rc signal handlers. All I want to know is, is it worth the effort? Also, what happens if you do: fn sigint { sleep 10 ... ... } is it the "right thing" that that sleep should be uninterruptible? Right now I'm just taking the easy way out. I'm not saying that's a good thing, but it will take some persuasion + real life examples to tell me that the present signal handling semantics are inadequate.