[lkml]   [1996]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SA_STACK
> > Maybe it would be better to forget the BSD style sigstack() and go
> > with the SYSV sigaltstack() ?
> > -Melvin

> Are you not sure of how to code setjmp()/sigsetjmp, or what they
> should do?

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.


 \ /
  Last update: 2005-03-22 13:37    [W:0.044 / U:2.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site