[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 <pipcet@gmail.com>
> Date: Fri, 12 Jul 2019 18:06:29 +0000
> Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org
>
> > 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.
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Andreas Politz, 2019/07/11
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation,
Eli Zaretskii <=
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/12
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/13
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/13
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/13
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/13
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/13
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Eli Zaretskii, 2019/07/13
- bug#36609: 27.0.50; Possible race-condition in threading implementation, Pip Cet, 2019/07/13