Neither. I think setjmp()/longjmp() work fine. At least they seem to be.
> 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
I think so too, my user-level thread routines use individual malloced()
stacks and I'm using the standard setjmp/lonjmp as is.
> but I believe the kernel only switches back to the 'main' stack when
> _all_ the alternative-stack signal handlers have returned.
Or someone does a longjmp() out of the sig-handler. That was the initial
problem I was talking about. In setup_frame() (sp?) in kernel where it
checks for an alt-stack, without a stack_size I don't know how I would
check if:
1) We are already on alt-stack
2) We are at end of stack
Using sigaltstack {} would solve this I think and would allow nested
signals to work by staying on alt-stack.
> 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!
I think so. It would be messy if it was not this way.
> 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
Another reason for sigaltstack() instead of sigstack()
> 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.
-Melvin