[PATCH, libgfortran] Remove recursion check

[Janne Blomqvist]

On Mon, Sep 24, 2018 at 7:48 PM Thomas Koenig <tkoenig@netcologne.de> wrote:

> Hi Janne,
>
> > libgfortran has a recursion check in the error handling paths.  This
> > works by checking the value of a static variable, and if it matches,
> > aborting immediately instead of continuing error processing.
> > Unfortunately, in a multi-threaded program, if two threads report an
> > error at the same time, this can trigger this check, and thus the
> > underlying reason for the error is never reported.
>
> I agree that this is a problem that should be addressed.  Hm...
>
> What do you think, would it be desirable / possible to keep the
> recursive error check, but ensure thread safety by a suitable
> locking mechanism?  As a first step, we should probably specify
> what exactly we would like to happen.
>
> Let us assume that the aim is to keep the current behavior for normal
> processes and allow concurrent error processing for multiple threads.
>
> This could be done by making the static variable thread-local.
> I'm not sure that this would work reliably, or if some sort of
> locking mechanism (probably involving PTHREAD_MUTEX_RECURSIVE)
> would be required - only have one thread at a time process
> an error.
>
> Do we actually want to keep the current behavior for non-threaded
> programs?  I'd be in favor, but I do not feel strongly about that.
>

What I briefly was thinking about doing, was to use TLS. Or rather, since
TLS is not supported on all targets, something like I did in
intrinsics/random.c:get_rand_state(). But, since the error handling stuff
should be async-signal-safe, the allocation in the setup path should be
done separately, e.g. as part of library initialization.

In the end I decided against it because

1) It's more complicated, in order to handle a quite unlikely edge case.

2) If recursion happens anyway, it's a bug in our error handling flow which
should be fixed and not be papered over.

Anyway, I'm not massively against this, if people have any particular
opinion lets hear it.

-- 
Janne Blomqvist