[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation
Date: Fri, 12 Jul 2019 21:27:40 +0300

> From: Pip Cet <address@hidden>
> Date: Fri, 12 Jul 2019 18:06:29 +0000
> Cc: address@hidden, address@hidden
> > Then we should make sure we release it when the thread function exits,
> That's too late, it's legitimate for the thread to have a signal
> handler. We need to release the lock at precisely the time that
> unbind_to would release it.

I had also another proposal:

> > or before we call Fsignal from post_acquire_global_lock.  There's no
> > reason to use the unwind-protect machinery for that, I think.
> If we call Fsignal, surely the unwind-protect machinery is already set
> up and we can safely call it? So unbind_to would work again...

Sorry, I don't want to call unwind-protect there.  Call me paranoid,
if you want.

> I guess I've changed my mind: the unwind-protect machinery does
> precisely what we want, we should simply document that thread_select
> can exit nonlocally and that the select functions need to be written
> to cater to that.
> Two places call xg_select, and they both run long after unbind_to works.
> Doing this without the unwind-protect machinery is difficult: for
> example, a comment in post_acquire_global_lock claims
> unbind_for_thread_switch can exit nonlocally, though I don't think
> that actually happens or we would have seen the bug report.
> What's your proposal for doing this?

Like I said: release the lock before calling Fsignal.  We could do
that before calling unbind_for_thread_switch, if needed.

reply via email to

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