>  > 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.)
	oh yeah...

> ...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.
	hmm... that makes sense.  Probably more useful to allow
debuggers to see that last signal.

> 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...)
	well, looking through the code a bit more:  using psignal is still
essentially immediate.  The process won't get past the CURSIG/postsig
loop because default actions are checked and done before handlers.

	writing a test case to actually get to the sigexit/psignal point
is a bit trickier than I thought.  oh well, guess it probably doesn't
happen all that often anyway.

eric
haszlaki@uaccess.net