# PEP 684: A Per-Interpreter GIL

**URL:** <https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583>\
**Category:** PEPs\
**Created:** [September 29, 2022, 11:05pm UTC](https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583 "2022-09-29T23:05:58Z")\
**Posts on this page:** 1\
**Showing post:** 34

<div class="post-metadata">

**Author:** ![gpshead](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gpshead/32/54_2.png) [@gpshead](https://discuss.python.org/u/gpshead)\
**Post date:** [November 9, 2022, 8:18am UTC](https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583/34 "2022-11-09T08:18:28Z")

</div>

> [@eric.snow](#):
>
> Would the faulthandler module be limited to the main interpreter (like the signal module) or would we leak that global state between interpreters (protected by a granular lock)?

`faulthandler` the crash reporting feature would remain per process. Just as it can do with dumping the current traceback of each thread in the VM, it should presumably be extended to do that for each subinterpreter so that it is clear which tracebacks belong to what.

`faulthandler.dump_traceback*` APIs could just dump thread stacks related to the calling interpreter? Or easier: simply restrict all faulthandler APIs to being called from the main interpreter rather than allowing them from subinterpreters. Given they deal with process wide state, just don’t let subinterpreters call them at all.

---

_[View the full topic](https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583)._