From: hugh@redvax.uucp ("D. Hugh Redelmeier")
To: rc@archone.tamu.edu
Subject: signal handling
Date: Wed, 2 Oct 1991 09:38:38 -0500 [thread overview]
Message-ID: <9110021438.AA06931@redvax> (raw)
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
next reply other threads:[~1991-10-02 15:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1991-10-02 14:38 "D. Hugh Redelmeier" [this message]
1991-10-03 22:03 ` Scott Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9110021438.AA06931@redvax \
--to=hugh@redvax.uucp \
--cc=rc@archone.tamu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).