Author vstinner
Recipients Mark.Shannon, eric.snow, jdemeyer, nascheme, ncoghlan, phsilva, steve.dower, vstinner
Date 2020-03-17.16:04:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1584461050.29.0.862094837495.issue36710@roundup.psfhosted.org>
In-reply-to
Content
> Instead of passing `_PyRuntimeState` around everywhere, why not just let it disappear in time.

Passing runtime (_PyRuntimeState) is a temporary move until more and more fields are moved from _PyRuntimeState into PyInterpreterState. I just created bpo-39984 "Move some ceval fields from _PyRuntime.ceval to PyInterpreterState.ceval" yesterday ;-)

Once we will manage to move the GIL into PyInterpreterState, we would still have to pass PyInterpreterState or PyThreadState to function which require to access the GIL. Passing explicitly runtime is a first step to prepare to migration to PyInterpreterState or PyThreadState. My intent is to show that many functions rely on "global variables": pass these variables instead.

If you are thinking about getting the current Python thread state using a thread local storage, that's a different topic and I'm not aware of an open issue to track this idea.


> Currently `_PyRuntimeState` manages "global" state, mainly the GIL and some config. Once the GIL has been migrated to the sub-interpreters, the config part can be factored out and `_PyRuntimeState` can just disappear.

I don't think that we will be able to fully remove _PyRuntimeState. It seems like the PEP 554 "Multiple Interpreters in the Stdlib" requires a registry of interpreters and it currently lives in _PyRuntimeState.
History
Date User Action Args
2020-03-17 16:04:10vstinnersetrecipients: + vstinner, nascheme, ncoghlan, phsilva, Mark.Shannon, eric.snow, jdemeyer, steve.dower
2020-03-17 16:04:10vstinnersetmessageid: <1584461050.29.0.862094837495.issue36710@roundup.psfhosted.org>
2020-03-17 16:04:10vstinnerlinkissue36710 messages
2020-03-17 16:04:10vstinnercreate