[issue32280] Expose `_PyRuntime` through a section name

Pablo Galindo Salgado added the comment: New changeset ebba286709bdb9401df8e5eb196b50008d3b09d2 by Miss Islington (bot) in branch '3.10': bpo-32280: Store _PyRuntime in a named section (GH-4802) (#27448) https://github.com/python/cpython/commit/ebba286709bdb9401df8e5eb196b50008d3b09d2

[issue32280] Expose `_PyRuntime` through a section name

Change by miss-islington : -- nosy: +miss-islington nosy_count: 12.0 -> 13.0 pull_requests: +25977 pull_request: https://github.com/python/cpython/pull/27448 ___ Python tracker

[issue32280] Expose `_PyRuntime` through a section name

Pablo Galindo Salgado added the comment: New changeset 35002aa8f62dda1f79035e9904abdf476683e9be by Max Bélanger in branch 'main': bpo-32280: Store _PyRuntime in a named section (GH-4802) https://github.com/python/cpython/commit/35002aa8f62dda1f79035e9904abdf476683e9be -- nosy:

[issue32280] Expose `_PyRuntime` through a section name

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue32280] Expose `_PyRuntime` through a section name

Steve Dower added the comment: It looks fine to me, but we probably want to clearly document it as unsupported/likely to change between releases/etc., especially since it's relying on an assumption that we want to change (one static runtime per process). --

[issue32280] Expose `_PyRuntime` through a section name

Cheryl Sabella added the comment: @steve.dower, please take a look at this PR when you have a chance. Thanks! -- nosy: +cheryl.sabella ___ Python tracker ___

[issue32280] Expose `_PyRuntime` through a section name

Maxime Belanger added the comment: Thanks for taking a look! To answer your question, the need for the named section comes not from the API being being "internal", but because we need to access it at runtime from a tool running in a separate process. We have augmented Crashpad (Google's

[issue32280] Expose `_PyRuntime` through a section name

Eric Snow added the comment: (Sorry for the delay!) Is the need for a named section due to the fact that _PyRuntime is part of the "internal" C-API (hidden behind the Py_BUILD_CORE macro)? I.E. would it help to build with Py_BUILD_CORE? Regarding the GIL: The plan for 3.9 is to have one

[issue32280] Expose `_PyRuntime` through a section name

Change by Eric Snow : -- versions: +Python 3.8 -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32280] Expose `_PyRuntime` through a section name

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___

[issue32280] Expose `_PyRuntime` through a section name

Maxime Belanger added the comment: Interesting, would this imply potentially multiple GILs? The major thing we need out of the structure is the (`Py_tss_t`) `autoTSSKey` in order to associate a native thread with its `PyThreadState`. --

[issue32280] Expose `_PyRuntime` through a section name

Eric Snow added the comment: Note that in the long term we are considering support for embedding multiple runtimes in a single process. So anything that assumes there is only a single runtime in each process is problematic. --

[issue32280] Expose `_PyRuntime` through a section name

Change by Max Bélanger : -- keywords: +patch pull_requests: +4700 stage: -> patch review ___ Python tracker ___

[issue32280] Expose `_PyRuntime` through a section name

Change by Steve Dower : -- nosy: +eric.snow ___ Python tracker ___ ___

[issue32280] Expose `_PyRuntime` through a section name

Change by Steve Dower : -- nosy: +ncoghlan ___ Python tracker ___ ___

[issue32280] Expose `_PyRuntime` through a section name

New submission from Maxime Belanger : We've recently been toying with more sophisticated crash reporting machinery for our Desktop Python application (which we deploy on macOS, Windows and Linux). To assist in debugging, we are storing `_PyRuntime` in a predictable location