[haiku-commits] Re: r41641 - haiku/branches/developer/bonefish/signals/headers/posix
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sun, 22 May 2011 22:36:55 +0200
On Sun, 22 May 2011 19:33:20 +0200 "François Revol" <revol@xxxxxxx> wrote:
> Le 22 mai 2011 à 18:36, François Revol a écrit :
>
> > Hmm why do this at all if it's not compatible with BeOS ?
> > Can't SA_SIGINFO handlers provide all the needed things anyway ?
>
> Ah disregard, just saw the next commit.
You've got a point there nonetheless. Currently three kinds of signal handlers
supported:
1. void handler(int signal [, void* userData, vregs registers]);
2. void handler(int signal [, void* userData, vregs* registers]);
3. void handler(int signal, siginfo_t* info, void* context
[, void* userData]);
The parameters in the brackets are additional parameters passed to the signal
handler that are not required by POSIX.
The first version is what BeOS supports. As userData the system passes what was
specified in the (non-POSIX extension) sigaction::sa_userdata field of the
structure given to sigaction(). The registers parameters describes the CPU
register state of the context interrupted by the signal delivery. Haiku (in my
branch) calls the handler this way as a binary compatibility feature when the
application code was compiled until alpha 3.[1]
The second version is used for new application code, when the handler was
specified with the SA_SIGINFO flag cleared. The reason for not just sticking
with the first version is that the first version is more expensive to set up --
the vregs structure (which is 556 bytes in size) has to be copied two more
times.[2]
The third version is used for new application code, when the handler was
specified with the SA_SIGINFO flag set. This is a new feature. The context
parameter is actually a ucontext_t* (ask Axel, what the Austin Group was
thinking :-)), which also contains a register environment.
So regarding your questions: Yes, the SA_SIGINFO style signal handlers (at
least with the userData extension) provide all needed info. New Haiku code
could use that, and the non-POSIX extension for the simple style handler (2.)
could as well be removed. There's just very little speaking for doing that. It
wouldn't exactly save any code (save for passing the two arguments [3]). And
since all three occurrences of code in the repository using the BeOS extension
only use the userData parameter, they didn't even have to be adjusted (well,
save for the sighandler_t cast, which I broke intentionally).
CU, Ingo
[1] Actually Haiku never correctly supported 1. It implemented 2., but that was
an unintentional bug.
[2] The reason for the additional copies is that (at least that's how I guess
the POSIX specs mean it to work) we have to create a ucontext_t on the user
stack even when the handler invoked is not SA_SIGINFO style handler, since the
ucontext_t::uc_link chains previous signal contexts and both signal handler
styles can be mixed in the same application code.
[3]
http://dev.haiku-os.org/browser/haiku/branches/developer/bonefish/signals/src/system/kernel/arch/x86/x86_signals.cpp?rev=41642#L49
Other related posts:
