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,
etc.)

 >     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                                       thorpej@nas.nasa.gov
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