develooper Front page | perl.perl5.porters | Postings from March 2015

Re: Tally of issues with FATAL warnings / RFC to explicitlydiscourage their use

Thread Previous | Thread Next
From:
Zefram
Date:
March 19, 2015 13:20
Subject:
Re: Tally of issues with FATAL warnings / RFC to explicitlydiscourage their use
Message ID:
20150319132000.GA28042@fysh.org
Peter Rabbitson wrote:
>First a small preamble: this thread was started as a place for
>exploration of the *technical drawbacks* of using FATAL warnings

ribasushi has (off-list) prodded me to look at this thread.  I swore
off debates about warnings years ago, because the issue is way too
subjective, so in the present discussion I don't want to take a position
on whether it is ever sensible for Perl code (library or otherwise) to
make warnings fatal.  But I'm willing to address the cleaner question
of the quality of the present implementation.

>- Hard interpreter crashes
>  - *NOT FIXED* as of 5.21.8
>
>    - RT#123398 [3]
>      A fatalized warning in a DESTROY method loops while being
>      re-converted to a regular warning, eventually blowing up the
>      containing process. This happens regardless of runtime or global
>      destruction PHASE.

Cute.  In principle this loop is a foreseeable consequence of the
combination of inherent semantics: exceptions during unwinding become
warnings, and warnings under fatalisation become exceptions.  The two
inherently fight.  For practicality, we should presumably resolve this by
suppressing fatalisation of warnings that result from the defatalisation
of cleanup-time exceptions.  It's worth comparing against what you get by
setting $SIG{__WARN__}: the handler is suppressed while it is executing,
so an equivalent loop cannot be constructed that way.

This doesn't strike me as the fault of fatal warnings; it's more about
the inherently tricky status of exceptions during unwinding.  One is
already well advised to be especially careful about running arbitrary
code in destructor methods, and the particular problems of fatalised
warnings are just another aspect of those special circumstances.  A doc
note about the specific interaction would be justified, if it can't
actually be resolved in time by a code change, but this is not a reason
to discourage the use of warning fatalisation in general.

>- Implicit-fork related problems
>  - *NOT FIXED* as of 5.21.8
>
>    - RT#118767 [4]
>      Incorrect setting of $? after qx()
>
>    - RT#96332 [5]
>      The fatalization is not suppressed within a forked child about
>      to fire off a system-induced exec(). This can lead to bizarre
>      non-actionable process continuation within the child.

These bugs are not specific to the fatal-warnings mechanism.  In both
cases, you can get the same bizarre results with

	use warnings;
	$SIG{__WARN__} = sub { die @_ };

I've run into a similar issue to the latter with IPC::Open3, with
an exception propagating in both processes.  My IPC::Filter has some
specific code to work around that.

So I don't blame the fatal-warnings mechanism for this problem either,
and in fact it's not even directly involved this time.  These problems
are about the interaction of exceptions with implicit fork.  Forking
internally in a subroutine is another case where the programmer must
have regard for the special circumstances in which the code will run.

The bunch of fixed bugs don't seem unusual for a Perl feature.  We get
a lot of tricky feature interactions and special cases.

So overall I don't think there's any smoking gun here saying that the
fatal-warnings mechanism is especially substandard, or in principle
unworkable.  There's a bunch of things that programmers need to be aware
of when writing for older Perl versions, but such backcompat issues exist
for all parts of Perl.  We haven't previously discouraged use of a feature
for this level of bugginess.  So there isn't a justification based on
implementation quality to discourage all use of fatal warnings, nor is it
fundamentally impossible to make it work satisfactorily.  (I reiterate,
I am silent on the wisdom of fatalising warnings in principle.)

-zefram

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About