This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients emilyemorehouse, eric.snow, nascheme, ncoghlan, pmpp, serhiy.storchaka, vstinner, yselivanov
Date 2018-09-17.15:41:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1537198918.45.0.956365154283.issue33608@psf.upfronthosting.co.za>
In-reply-to
Content
@Neil, we're definitely on the same page.  In fact, in a world where subinterpreters do not share a GIL, we can't ever use an object in one interpreter that was created in another (due to thread safety on refcounts).  The role of "tightly controlling" passing/sharing objects (for a very loose definition of "sharing") falls to the channels described in PEP 554. [1]

However, there are several circumstances where interpreters may collaborate that involves one holding a reference (but not using it) to an object owned by the other.  For instance, see PyBuffer_Release(). [2]  This issue is about addressing that situation safely.  It is definitely not about safely using objects from other interpreters.

[1] The low-level implementation, including channels, already exists in Modules/_xxsubinterpretersmodule.c.
[2] https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_Release
History
Date User Action Args
2018-09-17 15:41:58eric.snowsetrecipients: + eric.snow, nascheme, ncoghlan, vstinner, pmpp, serhiy.storchaka, yselivanov, emilyemorehouse
2018-09-17 15:41:58eric.snowsetmessageid: <1537198918.45.0.956365154283.issue33608@psf.upfronthosting.co.za>
2018-09-17 15:41:58eric.snowlinkissue33608 messages
2018-09-17 15:41:58eric.snowcreate