This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, libgfortran] Remove recursion check


On Sat, Oct 6, 2018 at 8:55 PM Thomas Koenig <tkoenig@netcologne.de> wrote:

> Hi Jerry,
>
> > Agree it should be fixed. I would think a mutex lock should work. Lock,
> > issue error message, unlock. Even if there is recursion, since there is
> > at least one error somewhere, It should be OK to pause the world to
> > issue the error, and come back and finish. AS I think about it, maybe
> > one global lock variable so that only one thread can get it at a time
> > and others wait until it is unlcoked to proceed with their lock and
> error.
>
> > Would there be a problem with some sort of endless loop waiting for the
> > unlock?
>
> I think that as long as we
>
> a) make the lock recursive
>
> b) make sure to unlock it afterwards
>
> we should be fine, we also should not enter an endless loop on
> the rare case of aa double error.
>
> I can prepare a patch, unless somebody else wants to do it.
>

The error handling functions can be called from a signal handler, so they
need to be async-signal-safe. See a list e.g. at
http://www.man7.org/linux/man-pages/man7/signal-safety.7.html . Notably,
none of the pthread mutex functions are there.

And come to think of it, neither are pthread_{g,s}etspecific(), so my idea
of using TLS a few messages earlier in this thread is probably not Ok
either..

-- 
Janne Blomqvist


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]