Re: signal blocking?

[John (Convulsed into oblivion from laughter or from fright) Mackin <john@vetsci.su.oz.au>]

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 <byron@archone.tamu.edu>
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
      <john@vetsci.su.oz.au>
Date: Wed, 22 Jan 1992 23:35:55 +1100
To: Byron Rakitzis <byron@archone.tamu.edu>
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 <byron@archone.tamu.edu>
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.