> Sorry I haven't gotten back to you sooner, Kyle.  Thanks for working on this.  I'm looking at your PR right now.

> BTW, Kyle, your problem-solving approach on this is on-track.  Don't get discouraged.  This stuff is tricky. :)

No problem at all, and thank you for the words of encouragement. (:

> Regarding "is_running()", notice that it relies almost entirely on "frame->f_executing".  That might not be enough (or maybe the behavior there changed).  That would be worth checking out.

Hmm, that's an interesting point that I hadn't considered. 

> @aeros, feel free too keep investigating.  I'd be glad to help you out.  Otherwise I'll dive into this probably next week.

Sounds good, I'll do some further digging around, particularly anywhere that interacts with PyFrameObject's `f_executing` field. I think it's possible that there's a non-obvious issue with `_is_running()`, where it works correctly 99% of the time. That seems to be a significant commonality between the different areas where the intermittent failures are occurring, they all directly or indirectly call `_is_running()`.

Also, thanks again Eric for the PR review. Looking back it after Eric's analysis and having a couple of months to think it over, I don't think that GH-16293 is the correct solution. It seems unlikely that this is being caused by a lack of proper GIL acquisition, as that would likely be causing far more consistent build failures. I'm thinking that it's more likely to be an issue with either:

1) Subinterpreters occasionally disappearing due to premature cleanup (as Eric suggested)

2) _is_running() being incorrect a small percentage of the time