> Maybe it would be better to forget the BSD style sigstack() and go
> with the SYSV sigaltstack() ?
> -Melvin
I prefer the SVR4 implementation, with the reasoning that I have
never used BSD's sigstack(). POSIX.2/XPG4 didn't tackle alternative
stacks, but someone should check up what the current working groups
are doing - there might well be in a new draft that covers this.
Are you not sure of how to code setjmp()/sigsetjmp, or what they
should do?
setjmp() and sigsetjmp() are usually defined as saving the 'stack
environment' - this sounds like _which_ stack as well, and I guess this
is what you are doing. I assume SVR4 systems build these library routines
upon getcontext(). This call uses a 'struct ucontext' which
allows the current stack to be fetched.
If you go with SVR4 I would recommend implementing the setcontext()/
getcontext() system call pair to build *jmp() with (and they are system
calls, not library routines - or were that last time I looked).
Also note, that a SIGSEGV due to the maximum stack size changes slightly
in behaviour if there is an alternative stack - can't remember how...
Nested signal handlers could be problem under Linux, which (again,
if I remember correctly - havn't got access to code at work) builds
stack frames for _all_ pending signals at once. This may help performance
but is ignoying in not allowing signal handlers to install different
handlers for pending signals.
Anyway, under SVR4, the kernel switches to the alternative stack
if the signal being delievered is marked as being SA_NOSTACK _and_
the current stack is not the alt-stack. This next bit needs checking
by someone with good doc - or access to a machine to test the theory -
but I believe the kernel only switches back to the 'main' stack when
_all_ the alternative-stack signal handlers have returned.
This means, that while a process is servicing a signal delievered on
the alt-stack, all other signals (whether installed SA_NOSTACK or not)
are also delievered on the alt-stack. Someone, please put me right if
I've got this wrong!
Finally, before delievering a sig on the alt-stack, check there
is enough space first, and post a SIGSEGV on the main stack if there
isn't. This won't ensure the stack won't overflow, but would be a
help in debugging the overflow (espically if we had SA_SIGINFO!).
Hmm.., just had a thought. It would be easier to implement user-
level threads if setjmp() didn't restore which stack....I need to
get on a true SVR4 box and check this out.
markhe