[PATCH 03 of 10] rust-cpython: mark PySharedState as Sync so &'PySharedState can be Send
yuya at tcha.org
Tue Sep 24 19:28:23 EDT 2019
On Tue, 24 Sep 2019 16:36:17 -0400, Augie Fackler wrote:
> > On Sep 23, 2019, at 18:50, Yuya Nishihara <yuya at tcha.org> wrote:
> > On Mon, 23 Sep 2019 15:37:07 -0400, Augie Fackler wrote:
> >>> On Sep 22, 2019, at 02:41, Yuya Nishihara <yuya at tcha.org> wrote:
> >>> # HG changeset patch
> >>> # User Yuya Nishihara <yuya at tcha.org>
> >>> # Date 1568674765 -32400
> >>> # Tue Sep 17 07:59:25 2019 +0900
> >>> # Node ID fcaf01804ac8198d52d141d642d5ef7c935360cc
> >>> # Parent 34a355c69f643f15ff46f4524c75137c08a8de3b
> >>> rust-cpython: mark PySharedState as Sync so &'PySharedState can be Send
> >> I asked some colleagues in the context of D6859, airlifting my comments from phabricator:
> >> I asked some coworkers, and they said:
> >>> I do not believe this to be correct. An object is Sync if it is *inherently* thread-safe. This object is not -- the first thing borrow_mut does is a racy read of mutably_borrowed.
> >> so I'm now leaning towards this being a bad idea.
> >> Also, since it's possible we could call back into Python code and *that* could release-and-reacquire the GIL, the GIL guarding is probably insufficient to make this a "safe lie".
> > My understanding is that Python<'a> is basically a mutex, and no other
> > Python thread is running while it is taken.
> That's right, with the caveat that if we have a situation where:
> Python -> Rust (has GIL) -> Python -> Rust (drops GIL)
I expect rust-cpython would prohibit that within the safe API, but I'm not
an expert. Raphaël, do you have any thought?
More information about the Mercurial-devel