alternate stacks for signal handlers

[Stephen Weeks]

> Also note that
> some system calls won't fail, but will return short counts.  I.e.,  if  I  am
> reading  from  a slow device, and I have gotten something, but not everything
> yet, and an interrupt arrives, then if the read returns -1 (with errno EINTR)
> then  I  would have no idea how much I got.  (POSIX actually allows this, but
> no Unix does this since it would be horrible.)  Thus the read will return and
> look  like all is ok, but you won't have gotten all you asked for even though
> you are not at EOF.

I don't think this is a problem, at least for the TextIO stuff, since
the low-level read calls don't ask for a specific amount, and just
deal with however much they get.

> Any way, you are right, the SA_RESTART will have to go.  I  was  hoping  that
> the  rest  of  the  code  would  not have to be aware of system calls failing
> because of signals, but I guess it does.

I think this problem could be alleviated by having all system calls
restarted at the ML level, within the basis library code.  After every 
system call, the library code would then check errno, and if it's
EINTR, would run the ML signal handler with a current thread that
knows to restart the system call.