Subject: Re: in kernel signalling
To: None <firstname.lastname@example.org>
From: Eric Haszlakiewicz <haszlaki@UAccess.NET>
Date: 04/27/1998 11:21:15
> > 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,
> ...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.