-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-38018: increase code coverage for multiprocessing.shared_memory #15662
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
Conversation
0008911
to
732de69
Compare
732de69
to
7af3ca3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first two checks look like good additions.
The use of mock to control the name of the shared memory segments does not look right to me -- have you verified that this test passes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test involving mock appears use two distinct names for the two SharedMemory(create=True, size=1)
invocations. Crudely adding a print()
to show shm1.name
and shm2.name
seems to confirm this. Hence the two tests that pass are against names[0]
and later names[1]
.
Perhaps I misunderstood but I thought the intent was to verify that _make_filename
creating duplicate names does not trigger a problem in and of itself.
@applio, The intent of the test is to verify if a problem is caused when Then I reset the side effect function of the mock object by So, _make_filename will now again return And then the loop will continue, calling So, therefore it verifies that existing segment names returned by |
Ahhh, thank you for the clarification. Got it. |
Thanks @vinay0410 for the PR, and @applio for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8. |
Sorry @vinay0410 and @applio, I had trouble checking out the |
This PR introduced a regression in FreeBSD buildbots: |
https://bugs.python.org/issue38018