[Python-Dev] PEP 554 v3 (new interpreters module) (original) (raw)
Koos Zevenhoven k7hoven at gmail.com
Wed Oct 4 11:54:39 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Next message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Oct 4, 2017 at 4:51 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > The problem relates to the fact that there aren't any memory barriers > around CPython's INCREF operations (they're implemented as an ordinary > C post-increment operation), so you can get the following scenario: > > * thread on CPU A has the sole reference (obrefcnt=1) > * thread on CPU B acquires a new reference, but hasn't pushed the > updated obrefcnt value back to the shared memory cache yet > * original thread on CPU A drops its reference, thinks the refcnt is > now zero, and deletes the object > * bad things now happen in CPU B as the thread running there tries to > use a deleted object :)
I'm not clear on where we'd run into this problem with channels. Mirroring your scenario: * interpreter A (in thread on CPU A) INCREFs the object (the GIL is still held) * interp A sends the object to the channel * interp B (in thread on CPU B) receives the object from the channel * the new reference is held until interp B DECREFs the object From what I see, at no point do we get a refcount of 0, such that there would be a race on the object being deleted. So what you're saying is that when Larry finishes the gilectomy, subinterpreters will work GIL-free too?-)
––Koos
The only problem I'm aware of (it dawned on me last night), is in the
case that the interpreter that created the object gets deleted before the object does. In that case we can't pass the deletion back to the original interpreter. (I don't think this problem is necessarily exclusive to the solution I've proposed for Bytes.)
-eric
Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ k7hoven%40gmail.com
--
- Koos Zevenhoven + http://twitter.com/k7hoven + -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171004/472a5336/attachment-0001.html>
- Previous message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Next message (by thread): [Python-Dev] PEP 554 v3 (new interpreters module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]