rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* signal handling
@ 1991-10-02 14:38 "D. Hugh Redelmeier"
  1991-10-03 22:03 ` Scott Schwartz
  0 siblings, 1 reply; 2+ messages in thread
From: "D. Hugh Redelmeier" @ 1991-10-02 14:38 UTC (permalink / raw)
  To: rc

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* signal handling
  1991-10-02 14:38 signal handling "D. Hugh Redelmeier"
@ 1991-10-03 22:03 ` Scott Schwartz
  0 siblings, 0 replies; 2+ messages in thread
From: Scott Schwartz @ 1991-10-03 22:03 UTC (permalink / raw)
  To: hugh; +Cc: rc


| I want a shell to be absolutely trustable.  

I strongly agree.

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

So what?  A shell is an OS specific tool.  If you want to quote
standards, POSIX is the one to quote.  BSD, at least, has reasonable
methods for dealing with signals.  It would be nice to take advantage
of them.



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1991-10-03 22:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1991-10-02 14:38 signal handling "D. Hugh Redelmeier"
1991-10-03 22:03 ` Scott Schwartz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).