On Wed, Jan 15, 2020 at 12:20 AM Kyle Stanley <report@bugs.python.org> wrote:
> As can be seen from the results above, the interpreter is not even running in the first place before
> it's destroyed, so of course destroy() won't raise an RuntimeError. I think this proves that
> interpreters.destroy() is _not_ where we should be focusing our efforts (at least for now). Instead,
> we should first investigate why it's not even running at this point.

Good catch.

> I suspect the issue _might_ be a race condition within the "_running()" context manager that's
> preventing the interpreter from being ran, but I'll have to do some further investigation.

Sounds good.

> Notably, a rather difficult and hard to explain side effect occurred from adding the new assertion.
> [snip]
> But, I have no explanation for this.

Yeah, that sounds a bit strange.  Keep in mind that there have been
other changes in this part of the runtime code, so this might be
related.  Or I suppose it could be a side effect of calling
is_running() (though that definitely should not have side effects).

> do you think it might be worth adding in the changes I made to DestroyTests.test_still_running above?

Yeah, it's a good sanity check on the assumptions made by the test.
Please do open a PR and request a review from me.