Author eric.snow
Recipients aeros, eric.snow
Date 2020-01-17.19:49:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CALFfu7D2fFxmPKEEENpUxMkjXpWLXKJ=H+gaxu2HEZ9zz1hP8A@mail.gmail.com>
In-reply-to <1579072848.56.0.254568201766.issue37224@roundup.psfhosted.org>
Content
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.
History
Date User Action Args
2020-01-17 19:49:57eric.snowsetrecipients: + eric.snow, aeros
2020-01-17 19:49:57eric.snowlinkissue37224 messages
2020-01-17 19:49:57eric.snowcreate