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 KubaO
Recipients JunyiXie, KubaO, eric.snow, h-vetinari, mloskot, pablogsal, rhettinger, vstinner
Date 2022-01-24.19:38:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I'm looking very much forward to isolated subinterpreters and thus the per-subinterpreter GIL, as I've been keeping a private exploratory project where I had to make them work.

Here are my thoughts:

1. Any sort of reference count on heavily used objects cannot be shared between the threads, even if its value is otherwise ignored. I.e., a write-only shared refcount is already a no-no. The mere fact that it's being modified from different threads is a performance bottleneck, as the cacheline that holds the refcount has to be shuttled between cores. That's a bad thing and the penalty only becomes worse as the time marches on.

2. For platforms where the C language supports thread-local storage (TLS) at the declaration level, it's trivial to have "global static" immortal objects become thread-local static. This could be perhaps an escape to keep old code working to an extent, as opposed to immediately breaking. On such platforms, the `PyGet_Foo` API can be on equal footing with the legacy `Py_Foo` statics, i.e. both would do the same thing. That's how I've done it in my experiment. The obvious problem is that on platforms without compiler support for TLS, `Py_Foo` would be unavailable, and that's probably a no-go for an API that wouldn't be deprecated. For portability, everyone should be using `PyGet_Foo`, iff platforms without language-level TLS support are of interest (are they? what would they be?)
Date User Action Args
2022-01-24 19:38:40KubaOsetrecipients: + KubaO, rhettinger, vstinner, eric.snow, mloskot, pablogsal, h-vetinari, JunyiXie
2022-01-24 19:38:40KubaOsetmessageid: <>
2022-01-24 19:38:40KubaOlinkissue39511 messages
2022-01-24 19:38:40KubaOcreate