New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[subinterpreters] PEP 554 implementation: add interpreters module #76785
Comments
In the interest of getting something landed for 3.7, so we can start using it in tests, I'm putting up a patch for a low-level interpreters module. In some ways this is a precursor for issue bpo-30439, which will add a proper public stdlib module in 3.8. The module I'm adding draws from the ideas in PEP-554 (particularly for channels). Consequently, this will also give us an opportunity to try out some of the semantics from the PEP to give us better ideas for 3.8. I expect to have some follow-on patches to facilitate simpler use in tests. This patch is big enough already. :) |
@ned, it may be a little tight to land this given the time left before beta 1. However, this is meant as a tool for us to use in the test suite (particularly to test the subinterpreter C-API). So I'm arguing that, if necessary, it would still be okay to land this after the feature freeze. (I'm still hoping to get this in before the cutoff.) What do you think? |
FYI, there are a few things I need to clean up in the PR. However, I expect that those changes will be minor relative to the the whole patch, so I wanted to get the ball rolling on a review. :) |
@eric, given the breadth of change introduced in the PR (including adding a new extension), I think it would be best if at all possible to get it in for beta 1 if we can resolve the review comments in time. If necessary and if there are no objections from other core developers, I would be willing to consider making an exception and allowing it into beta 2 as long as it remains a private interface. If it looks like it won't be in releasable shape by then, I think you should hold off for 3.8; doing otherwise would be unfair to others and to our downstream beta users / testers, for example, even if it is private, adding a new extension and setup.py changes potentially affect downstream packagers. |
Sounds good, Ned. Thanks for taking a look. I should have everything finished up by Friday, so I'm hopeful for landing the change before the deadline. I may have a few minor tweaks to make after that, but I'll discuss that with you before making any changes if that happens. |
I've merged the patch without Windows support, which shouldn't be a problem given the purpose of the extension module. I've also added a PR for get the module building under Windows. I'd like to get that resolved ASAP. |
Eric, looks like some buildbots are unhappy, for instance: |
Yeah, I'm looking into it. Also, I noticed some refleaks that I'll be sorting out. |
On 4 of the buildbots: ====================================================================== Traceback (most recent call last):
File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 890, in test_drop_multiple_times
interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3) ====================================================================== Traceback (most recent call last):
File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 848, in test_drop_single_user
interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3) ====================================================================== Traceback (most recent call last):
File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 957, in test_drop_used_multiple_times_by_single_user
interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3) ====================================================================== Traceback (most recent call last):
File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test__xxsubinterpreters.py", line 899, in test_drop_with_unused_items
interpreters.channel_drop_interpreter(cid, send=True, recv=True)
SystemError: More keyword list entries (7) than format specifiers (3) |
On the PPC64 AIX 3.x buildbot: ====================================================================== Traceback (most recent call last):
File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test__xxsubinterpreters.py", line 784, in test_repr
self.assertEqual(repr(cid), 'ChannelID(10)')
AssertionError: 'ChannelID(0)' != 'ChannelID(10)'
- ChannelID(0)
+ ChannelID(10)
? + |
I just put up a PR that should fix the 4 buildbots. |
The buildbots should be happier now. I'll keep an eye on them. |
A couple defects reported by coverity: ** CID 1428758: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /Modules/_xxsubinterpretersmodule.c: 45 in _coerce_id() 1217 } |
I've landed a PR that fixes all the memory leaks in the module. It also fixes the 2 defects reported by coverity. The only thing left here is to get the module building under Windows. |
FYI, out of 2389 source lines in the C extension, 1563 are the channel-related code. That means the non-channel code is 826 lines (about a third). That non-channel code does not depend on the channel code at all and I considered splitting the source out, but figured there wasn't enough benefit. However, I might revisit the matter later when I circle back to PEP-554. :) |
Eric, it looks like your recent commit introduced a refleak. We need to fix it before beta2. ~/d/p/cpython (master $) » ./python.exe -m test -R3:3 test_multiprocessing_fork 1 test failed: And just before it: ~/d/p/cpython ((bd09335…) $) » ./python.exe -m test -R3:3 test_multiprocessing_fork Total duration: 9 min 12 sec |
Also see bpo-24553. |
The commit a1d9e0a introduced reference leaks: $ ./python -m test -R 3:3 test__xxsubinterpreters -m test.test__xxsubinterpreters.RunFailedTests.test_traceback_propagated
(...)
test__xxsubinterpreters leaked [1863, 1861, 1863] references, sum=5587
test__xxsubinterpreters leaked [559, 558, 559] memory blocks, sum=1676
(...) |
The buildbots are broken for one whole week and nobody is available to investigate the reference leak regression. Following the CI policy, I wrote PR 20089 to revert the change which broke the CI: If someone wants to push again the change, make sure that "./python -m test -R 3:3 test__xxsubinterpreters" does not leak. |
The revert fixed the test: $ ./python -m test -R 3:3 test__xxsubinterpreters
(...)
Tests result: SUCCESS |
The new test leaks references: https://buildbot.python.org/all/#/builders/563/builds/105 test_interpreters leaked [216, 216, 216] references, sum=648 Use "./python -m test.bisect_cmd -R 3:3 test_interpreters" to find tests which leak. Example: $ ./python -m test test_interpreters -R 3:3 -m test.test_interpreters.TestInterpreterDestroy.test_from_current
0:00:00 load avg: 0.82 Run tests sequentially
0:00:00 load avg: 0.82 [1/1] test_interpreters
beginning 6 repetitions
123456
......
test_interpreters leaked [36, 36, 36] references, sum=108
test_interpreters leaked [14, 14, 14] memory blocks, sum=42
test_interpreters failed == Tests result: FAILURE == 1 test failed: Total duration: 1.3 sec |
I will look at this tommorrow. Am abit busy today. Thanks Victor |
Commit 9d17cbf is causing all refleak buildbots to fail and is masking other issues and causing some confusion already in other PRs (like #20433) so I opened a revert in PR 20465 following the buildbot revert policy (https://discuss.python.org/t/policy-to-revert-commits-on-buildbot-failure/404). Please, open a new PR with this change again once the refleaks have been resolved. |
The following test is enough to reproduce the leak: import unittest
import _xxsubinterpreters as _interpreters
class TestInterpreterDestroy(unittest.TestCase):
def tearDown(self):
for interp_id in _interpreters.list_all():
if interp_id == 0: # main
continue
_interpreters.destroy(interp_id)
def test_from_current(self):
interp_id = _interpreters.create(isolated=True)
_interpreters.run_string(interp_id, "import select") |
test__xxsubinterpreters and test_interpreters failed on AMD64 FreeBSD Shared 3.x: See also bpo-37224: "[subinterpreters] test__xxsubinterpreters fails randomly". IMO there are multiple race conditions in these tests. ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test__xxsubinterpreters.py", line 478, in test_subinterpreter
self.assertTrue(interpreters.is_running(interp))
AssertionError: False is not true ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_interpreters.py", line 309, in test_still_running
interp.close()
AssertionError: RuntimeError not raised ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_interpreters.py", line 207, in test_subinterpreter
self.assertTrue(interp.is_running())
AssertionError: False is not true ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_interpreters.py", line 383, in test_already_running
self.interp.run('print("spam")')
AssertionError: RuntimeError not raised |
Joannah, Eric, could you look into this? Having random failures in the builbots can make debugging more challenging, hide other issues and can also spam the buildbot list :( |
@pablo, yeah, I'll try to take a look this week. Are these new failures? Keep in mind that these tests can sometimes expose existing bugs in our runtime (as we fix runtime issues elsewhere) rather than regressions, though that isn't necessarily the case here. :) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: