lkml.org 
[lkml]   [1997]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: why do we put code onto the stack when doing a signal?
From
Date

> When SA_SIGINFO is implemented, we can have a different number of
> arguments on the stack-frame for a signal handler. (SA_SIGINFO adds two
> extra arguments, a "siginfo_t *" and "ucontext_t *" - I must find time to
> do this...).
> A libc signal return function would need to act as the signal-handler
> caller, which can be difficult as it wouldn't know how may args are on the
> stack.
>
> SVR4 use to (maybe it still does) use this method - it was v. ugly (all
> signals were delievered to a single library function, which called the
> appriopate handler!!!).

At least Solaris 2.x still does this on the SPARC. At signal delivey
time, sigacthandler in libc is invoked, which in turn calls the
signal handler and onec the signal handler returns it uses the
setcontext system call to restore execution to the point where the
signal was generated.

I like the idea of having setcontext/getcontext and delivering a
siginfo_t and a ucontext_t to those signal handlers that request it.

The cute thing about setcontext/getcontext is that any newcomer to
Linux can write his own thread package in userland in a couple of
hours :-). I know, I know we have the superior clone. I just liked
the fact that SVR4 had a decent way of getting/setting the process
execution context.

Miguel
--
miguel@roxanne.nuclecu.unam.mx
The GNU Midnight Commander: http://mc.blackdown.org/mc
Linux/SPARC project: http://www.geog.ubc.ca/sparclinux.html

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