Hi Richard, On Tue, Feb 2, 2016 at 6:11 PM, Richard Plangger <planri...@gmail.com> wrote: > * There is one path in call_release_gil (just after the call) where > rpy_fastgil was acquired (because it as 0) and the shadowstack is not > the one of the current thread. Then *rpy_fastgil = 0 is set for the > slowpath function. > Wouldn't it be possible to steal the gil at this point? Would that lead > to a problem?
No, it's not a problem: setting *rpy_fastgil to zero releases the GIL again, and it will be re-acquired again by the called function (at reacqgil_addr). There is no issue if the GIL is re-acquired by a different thread exactly here; we will simply block in reacqgil_addr. Note that we should in theory do a "lwsync" just before setting *rpy_fastgil to zero, like we do in call_releasegil_addr_and_move_real_arguments(). It's not done, but I *think* it doesn't hurt in this particular case. I may actually be very wrong, but I base my reasoning on these facts: 1) "*rpy_fastgil=0" can always appear to occur later, from the point of view of other processors, which is not a problem 2) in this case the "*rpy_fastgil=0" cannot appear to occur too early: it must appear after the "stdcxx" instruction changed it to 1, and there is no other store between that "stdcxx" and the following "*rpy_fastgil=0". So "lwsync" is not useful here. A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
