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.