GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing github.com — Requiring A Current Thread State for PyThreadState_Clear(), etc. is Problematic · Issue #101436 · python/cpython Open Labels 3.12only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-subinterpreterstype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DescriptionIn
For (FWIW, it isn't clear to me yet why we don't see frequent crashes from this already (at least when we're clearing the main interpreter during finalization). I do suspect that this contributes to some of the occasional CI failures we see relative to finalization.) Ideally auditing and the various object finalizers could work without having a current thread state, especially in the case where the current thread state could only possibly be the one getting cleared. Could we split up (Note that we'd still require that the GIL be held by the current OS thread when FTR, in gh-101308 I noted various cases where the lifecycle of thread states has an unexpected status. Pretty much all of them relate `PyThreadState_Clear()` requiring a current thread state.Dealing with the main issue above would make it trivial to address the following:
Activity
MetadataMetadataAssigneesLabels3.12only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-subinterpreterstype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error Projects
MilestoneRelationshipsDevelopmentIssue actions |
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |