Messages in this thread |  | | From | Hemment_Mark/ | Date | Mon, 20 May 96 17:16:32 +0100 | Subject | Re: SA_STACK |
| |
> Melvin wrote: >> markhe wrote: >> Hmm.., just had a thought. It would be easier to implement user- >> level threads if setjmp() didn't restore which stack....I need to
> 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
|  |