> I don't think so, at least in my thread routines I rely
> on saving/restoring
> which stack, not saying the way I'm doing it is right though.
OK, I've found an SVR4 box here that I can log-on to (I'm a contractor
here, and only just found out they had such a beast).
It's an DGUX 5.4R3.10, and I've normally found that DG are pretty
well pure SVR4 (didn't they by rights to the source from USL - before
SCO brought the hole business?).
I've tried out nested signals, longjmp()s, siglongjmp()s, and
setcontext() from within signal handlers.
1) Sigs delievered within a handler that is using an alt-stack are
also delievered on the alt-stack independent of whether they
were installed as SA_ONSTACK. As you said, this makes sense.
2) setjmp() and sigsetjmp() do _not_ store the current stack, or
if they do, longjmp() and siglongjmp() ignore it. When in a
signal handler, running on an alt-stack, performs a *longjmp()
the process continues running on the alt-stack (at least a call
to altsigstack() reports the alt-stack is in use). You were
right, this is wrong - simply returning from a function after a
*longjmp() causes a core dump!!!!
3) getcontext() _does_ store the current stack, and setcontext()
correctly restores. Both for the alt-stack and the main stack.
When in a sig hanlder, running on an alt-stack, performs a
setcontext(), the process continues execution on the stack at
the time of getcontext().
If you're *setjmp()/*longjmp() routines are working correctly with
alt-stacks, congradulations(sp?). I'm still v. much in favour of
having a get/setcontext(), but that's probably just me...
markhe