On Mon, Sep 24, 2018 at 7:48 PM Thomas Koenig <tkoe...@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
