Subject: Re: in kernel signalling
To: Eric Haszlakiewicz <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 04/26/1998 13:22:12
On Sun, 26 Apr 1998 00:31:21 -0500 (CDT)
Eric Haszlakiewicz <haszlaki@UAccess.NET> wrote:
> I was looking through alpha/machdep.c and noticed the sendsig(...)
> function seems to go through a lot of trouble when killing a process. It
> ends up re-signalling the process instead of just calling sigexit(...)
> like the i386 machdep does. (haven't looked at any others)
Most ports do it like the Alpha port does, actually...
> I was wondering why it does this.
> It would appear to be clearer to simply call sigexit, not mention it ends up
> being a much shorter code path. Also the ensuing core dump wouldn't have
> any changed value for the SIGILL handler which could cause confusion if,
> while debugging the dump, you happened to look at that.
> The only reason I found for using this method is that you'd get a
> final ktrace output for the signal, but wouldn't the core dump contain
> what signal the program crashed with anyway?
...yes, but for whatever reason, the program may not dump core... (limits,
> Is there some other reason for doing this that I'm missing?
I dunno... certainly, I think changing it to a sigexit() will _work_...
...hm, there are some other subtle things here... for example, if a
process is being traced (e.g. via ptrace(2)), using psignal() will
give the debugger a chance to look at things... sigexit() won't.
However, sigexit() will cause the process to exit _immediately_, as
opposed to psignal(), which may not...maybe it'll linger forever?
(Although, the process is already running given that we're in sendsig(),
so I might be wrong, here...)
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-5 Work: +1 650 604 0935
Moffett Field, CA 94035 Pager: +1 415 428 6939