> On Wed, 19 Jul 2006, Jerry D. Hedden wrote:
> > In the above, the thread 'die's which results in a warning. (In
> > and of itself, this would not terminate the application.) The
> > warning is then intercepted by the thread's warning handler which
> > subsequently executes an 'exit'. This results in the whole
> > application terminating.
>
> I do understand that, it just doesn't feel right to me. A call to
> die() should be roughly equivalent to:
>
> sub die {
> &{$SIG{__DIE__}}($_[0]) if defined $SIG{__DIE__};
> if ($^S) {
> $@ = $_[0] || "Died";
> # append "at ..." to $@
> # throw exception caught by eval block (longjmp)
> }
> exit($! || ($? >> 8) || 255);
> }
>
> I don't understand why you would call the __WARN__ handler instead
> of the __DIE__ handler just because this is not the main thread, and
> why die() without an eval block would not terminate the application
> the same way as a call to exit().
>
> I don't understand the reasoning why die() outside an eval block
> should be treated differently from the exit(). You can use all the
> same reasoning that it should terminate the application as you can
> for the exit() case.
Let me be more detailed.
First of all, a thread executes inside an eval via call_sv:
len = (int)call_sv(thread->init_function, thread->gimme|G_EVAL);
Now, if the thread executes a 'die', the 'die' does whatever it
normally does, including executing any die handler, and then the
thread returns from the call_sv.
The XS code then checks on $@ and if set, outputs a warning that
the thread terminated abnormally:
if (SvTRUE(ERRSV) && ckWARN_d(WARN_THREADS)) {
Perl_warn(aTHX_ "Thread %" UVuf " terminated abnormally: %" SVf,
thread->tid, ERRSV);
So far, that's the way it's always been.
Continuing, this warning is issued in the thread's context, so if
the thread has a warn handler, it will get executed.
If that warn handler subsequently executes a 'die', it does
whatever, including executing any die handler, and thread
termination continues, but the application does not terminate.
(This is a change that was agreed upon previous to the current
'exit' discussion. It used to be that the app would terminate at
this point.)
If the warn handler executes an 'exit', that will lead to
application termination. (This is the currently desired behavior
that I am restoring.)
