bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36609: 27.0.50; Possible race-condition in threading implementation


From: Pip Cet
Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation
Date: Sat, 13 Jul 2019 15:57:17 +0000

On Sat, Jul 13, 2019 at 3:54 PM Eli Zaretskii <address@hidden> wrote:
> > But I still would like to understand why we need to maintain a flag
> > per thread.

We don't. I had originally planned to make reacquiring the lock fail
gracefully if we can't spin-lock, but that didn't make it into the
patch, so it should be simplified as you suggest.

> Specifically, why not make this flag thread-independent, and have any
> thread release the context lock if that variable is non-zero?  I don't
> think it matters which thread locked the Glib context, we just need to
> release it once we emerge from thread_select, and do it before we
> might call Fsignal.  That the lock might be released by a thread other
> than the one which locked it shouldn't matter, I think, as long as we
> consider all the Lisp threads acting together on behalf of Emacs.

I agree entirely.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]