All commit authors signed the Contributor License Agreement.

Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip news label instead.

Whoops I messed up the documentation part. The tracking part should be on unlink, not on close.

@serhiy-storchaka Do you have any experience with this code? Could you help me with the review?

The new parameter needs tests.

No, I have no experience with this code. I can help with technical review, but I can't say whether the proposed feature is the right way to solve the problem.

It looks liketrack=False only affects POSIX. What about Windows? Should it raise an exception fortrack=False? Or fortrack=True?

If in most casestrack should be False ifcreate is false, should nottrack be set tocreate by default?

Thanks,@serhiy-storchaka -- let's see what the PR author says.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Thanks everyone!

Yes, the tracking only happens on POSIX because Windows has its own reference counting. I was cautious about mentioning this because users shouldn't rely on such internal behavior. But I can see that Windows users might that need it as a word of caution to thoroughly test their shared memory deallocation on other systems.

Outside of multiprocessing, each Python process comes with its own resource tracker which (assumingtrack isTrue) cleans up on termination. If some process shares memory with some short-lived subprocess, then the subprocess process tracker will warn that the user failed to clean up and delete the shared memory. The main process can then either unlink to get a FileNotFoundError or do nothing and be warned by its own resource tracker that the memory wasn't cleaned up properly (right after, the resource tracker will warn about its own FileNotFoundError).

Surely the resource tracker itself would need some deeper changes to be more robust but it's not my area of expertise either which is why I have opted for these minimal changes.

Windows must not raise an exception for eithertrack value! That would make the code nonportable with no gains.

As far as I understand there is a clash between multiprocessing and subprocess. Users of subprocess always want to disable tracking when not creating. For multiprocessing I use the higher level constructs and therefore never had the need to access the SharedMemory module directly. So while users of SharedMemory typically wanttrack andcreate to have the same value, the internals of multiprocessing may depend ontrack always beingTrue.

I will look into adding suitable tests now.

@pitrou Can you complete this review? I really don't know enough about this topic to review it properly.

@pitrou It looks like this is being held on your request from 3 weeks ago. I believe that@pan324 made the changes you requested.

Could you look at this and either release it or confirm that you still don't think the unit tests are sufficient?

Thanks.