[PATCH 03 of 10] rust-cpython: mark PySharedState as Sync so &'PySharedState can be Send
raf at durin42.com
Tue Sep 24 16:36:17 EDT 2019
> 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)
we're now potentially in a weird place. I'm not sure if I should worry about this. Supposedly we should spend some time browsing soundness bugs in PyO3 to get a sense of things?
> I can add some Mutex to make PySharedState inherently be Sync, but do we
> need such thing?
I'm honestly not sure anymore. :(
More information about the Mercurial-devel