From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from yonge.csri.toronto.edu ([128.100.1.2]) by archone.tamu.edu with SMTP id <18924>; Wed, 2 Oct 1991 10:48:29 -0500
Received: by yonge.csri.toronto.edu with UUCP id <241>; Wed, 2 Oct 1991 11:47:37 -0400
Received: by redvax (4.0/SMI-4.0)
	id AA06931; Wed, 2 Oct 91 10:38:38 EDT
Date: Wed, 2 Oct 1991 09:38:38 -0500
From: hugh@redvax.uucp ("D. Hugh Redelmeier")
Message-Id: <9110021438.AA06931@redvax>
To: rc@archone.tamu.edu
Subject: signal handling

I have not looked at rc's signal handling code, but the last couple
of messages make me concerned.

I want a shell to be absolutely trustable.  I think that there is
only one (onerous) style in which to use signal handlers safely.  I
infer that neither Byron nor John advocate this style.  If someone
is going to hack on rc to improve signals, I would like to at least
propose this approach.

The only safe things that a signal handler can do are
(according to ANSI):

- call signal() (no other library routine may be called)

- assign to a static variable of type "volatile sig_atomic_t"
  (no other variables may be fetched or stored)


Here is my suggestion for a signal handler.  It simple records each
signal.

	volatile sig_atomic_t
		sq_head = 0,
		sq_tail = 0,
		sig_queue[SQ_ROOF];

	void
	sig_catcher(int sig_no)
	{
		int	t = sq_tail;
		int nt = (t+1) % SQ_ROOF;

		if (nt == sq_head)
			return;	/* queue full: go home */
		sig_queue[t] = sig_no;
		sq_tail = nt;
		signal(sig_no, sig_catcher);
	}

This code is almost safe.  

- ANSI doesn't promise that sq_head or sq_tail can be safely fetched.
  I figure that they probably can.

- It can lose signals that happen while it is running.

- It can be crashed by the same signal happening twice quickly
  (exercise: change to "safe signals")

- sig_queue can overflow.

- On BSD systems, I/O to "slow" devices will be resumed!  The fix is
  to have the signal handler do a longjmp if slow I/O is being
  performed.  Ugh.

Every path in rc that can take a long time must be "cut" by a
signal-poll.

	if (sq_head != sq_tail)
		dispatch_signals();

Clearly, all data structures must be in a consistent state when this
polling is done, or we have bought nothing.  The routine
dispatch_signals() should be more-or-less similar to what is now
done in the signal handler.

I know that this is quite unpleasant.  I think that it is worthwhile.

Hugh Redelmeier
{utcsri, yunexus, uunet!attcan, utzoo, scocan}!redvax!hugh
When all else fails: hugh@csri.toronto.edu
+1 416 482-8253