Re: signal blocking?

Re: signal blocking?

[Chet Ramey]

> | Get this.  The function works ok with the version of rc linked with
> | the readline library, and bombs on the version without it.  Sigh.
> 
> That's because readline ignores the return code from read(), while
> Byron carefully checks it.

Oh, please, give me a break.  Why not check these things out before
shooting from the hip?

From rl_getc:

      result = read (fileno (stream), &c, sizeof (unsigned char));

      if (result == sizeof (unsigned char))
        return (c);

      /* If zero characters are returned, then the file that we are
         reading from is empty!  Return EOF in that case. */
      if (result == 0)
        return (EOF);

		... and so on ...

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Re: signal blocking?

[schwartz]

| Oh, please, give me a break.  Why not check these things out before
| shooting from the hip?

Hey, take it easy.  Actually, I did check; unfortunately it was the
editline source I looked at.  Honest mistake, ok?

Re: signal blocking?

[Byron Rakitzis]

Ok, it seems this application of signal handlers is as "real" as
they get.

re: putting a "return" in the signal handler. This is not going to
do a lot of good, since setting $status never changes the value of
errno in any case. I have specifically made signal handler invocations
different from function invocations (no "return" is allowed) so
that one could realize that it is not a very meaningful thing to
set $status in a signal handler.

It seems that the fundamental limitation here is not the ability
of rc to queue signals inside a signal handler, but rather the
system call/errno interface. read() returns a -1 on failure---any
kind of failure---and then you have to check errno to see what the
error really was. When a signal handler buggers the value of errno
you are really done for.

Therefore my initial reaction would be to have a signal handler do
a save/restore of errno, and preserve the v7 semantics of rc signal
handlers; I don't really feel like changing the way signals are
done in rc right now. It still seems like too much work, and the
current problem can be solved with this code:

; fn sigwinch {handle}
; fn handle {
	fn sigwinch
	stty
	fn sigwinch {handle}
}

(I just tried this on a NeXT and a Sun, with a save/restore of
errno in fn_handler, and a window-size-change on a terminal window)

Anyway, here's a context diff for fn.c:

*** fn.c.orig	Sun Mar 29 10:32:36 1992
--- fn.c	Wed Apr  8 10:39:35 1992
***************
*** 4,9 ****
--- 4,10 ----
  */
  
  #include <signal.h>
+ #include <errno.h>
  #include "rc.h"
  #include "sigmsgs.h"
  
***************
*** 84,91 ****
--- 85,94 ----
  static void fn_handler(int s) {
  	List *dollarzero;
  	Estack e;
+ 	int olderrno;
  	if (s < 1 || s >= NUMOFSIGNALS)
  		panic("unknown signal");
+ 	olderrno = errno;
  	dollarzero = nnew(List);
  	dollarzero->w = signals[s][0];
  	dollarzero->n = NULL;
***************
*** 94,99 ****
--- 97,103 ----
  	walk(handlers[s], TRUE);
  	varrm("*", TRUE);
  	unexcept(); /* eVarstack */
+ 	errno = olderrno;
  }
  
  /*

Re: signal blocking?

[Arnold Robbins]

Get this.  The function works ok with the version of rc linked with
the readline library, and bombs on the version without it.  Sigh.

Arnold

Re: signal blocking?

[schwartz]

| Get this.  The function works ok with the version of rc linked with
| the readline library, and bombs on the version without it.  Sigh.

That's because readline ignores the return code from read(), while
Byron carefully checks it.

Re: signal blocking?

[Arnold Robbins]

> To: arnold@cc.gatech.edu (Arnold Robbins)
> Cc: rc@archone.tamu.edu
> Subject: Re: signal blocking? 
> Date: 	Tue, 7 Apr 1992 18:12:20 -0400
> From: schwartz@groucho.cs.psu.edu
> 
> | So I need to temporarily block
> | SIGWINCH (ignore it basically) inside my SIGWINCH handler.
> 
> fn sigfoo {}  should set SIGFOO to SIG_IGN.  Will that do it for you?

No, since I need to do it inside the handler for SIGFOO...

> I notice that if I write
> 
> ; fn sigwinch { stty }
> 
> and then resize my xterm, rc exits fdgchar with ``read: No such file or
> directory''.
> 
> (This is on a Sun4 under SunOS 4.1.1.)

This is the result I was getting, although I didn't know where in rc
it was coming from; that's why I added the sleep.

Arnold

signal blocking?

[Arnold Robbins]

Is there an easy way to block a signal inside a signal handler?  I'm using
MGR from BellCore (fast!), and I've been trying to set up a signal handler
for SIGWINCH so that the rows and columns in stty get reset whenever I resize
a window.  However, when you do an stty of the rows and columns, MGR
kindly sends you another SIGWINCH too!  So I need to temporarily block
SIGWINCH (ignore it basically) inside my SIGWINCH handler.

Here's what I ended up doing.  Simple, but not terribly elegant.  Note
that the trailing sleep is needed or else the SIGWINCH comes in before
we're ready.

fn handle_winch {
size=() {
	fn sigwinch 	# temporary
	stty -echo
	echo '^[4I'
	size=(`{gawk '{ printf "%d %d\n", $3/12, $4/20 ; exit }'})
	stty echo
	stty columns $size(1) rows $size(2)
	sleep 1
	fn sigwinch { handle_winch }
} }

fn sigwinch { handle_winch }
--
Arnold Robbins --- College of Computing			| Laundry increases
Georgia Tech, Atlanta, GA 30332-0280			| exponentially in the
Domain: arnold@cc.gatech.edu	 Phone: +1 404 894 9214 | number of children.
UUCP: uunet!cc.gatech.edu!arnold FAX:   +1 404 853 9378 |  -- Miriam Robbins

Re: signal blocking?

[schwartz]

| I'm using MGR from BellCore (fast!), 

Yeah, MGR is neat... everyone should check it out.

| So I need to temporarily block
| SIGWINCH (ignore it basically) inside my SIGWINCH handler.

fn sigfoo {}  should set SIGFOO to SIG_IGN.  Will that do it for you?

I notice that if I write

; fn sigwinch { stty }

and then resize my xterm, rc exits fdgchar with ``read: No such file or
directory''.

(This is on a Sun4 under SunOS 4.1.1.)

Re: signal blocking?

[John Mackin]

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.