Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

gh-116738: Make mmap module thread-safe#139237

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
kumaraditya303 merged 7 commits intopython:mainfromyoney:ft_mmap
Oct 9, 2025

Conversation

@yoney
Copy link
Contributor

@yoneyyoney commentedSep 22, 2025•
edited by bedevere-appbot
Loading

These changes make themmap module thread-safe for FT-Python by protecting themmap_object against race conditions and undefined behavior. The goal is to provide behavior similar to standard Python builds with the GIL enabled, rather than makingmmap fully deterministic or generally recommended for multithreaded use.

cc:@mpage@colesbury@Yhg1s

@yoneyyoney marked this pull request as ready for reviewSeptember 22, 2025 15:01
Copy link
Member

@ZeroIntensityZeroIntensity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think that it would be helpful in the long run to switchmmap to AC rather than manually addinglock_held functions everywhere.

corona10 reacted with thumbs up emoji
@corona10
Copy link
Member

Same question from my side:
Why don t we switch to use AC with '@critical_section'?

@yoney
Copy link
ContributorAuthor

Same question from my side: Why don t we switch to use AC with '@critical_section'?

@ZeroIntensity,@corona10: Thank you both for the reviews, I agree that using AC with@critical_section would be a better.

I wanted to ask for your preference: would you like to implement the switch in this PR, or should I hold off on this one and do the implementation separately, then continue with this PR after that? Alternatively, the switch could be done as a follow-up PR.

Thanks!

@ZeroIntensity
Copy link
Member

Let's do AC in this PR.

yoney and corona10 reacted with thumbs up emoji

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM. I reviewedmmapmodule.c, but I didn't reviewLib/test/test_free_threading/test_mmap.py.

@kumaraditya303kumaraditya303 added the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelOct 8, 2025
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by@kumaraditya303 for commit9d6b95d 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F139237%2Fmerge

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

@bedevere-botbedevere-bot removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelOct 8, 2025
@kumaraditya303kumaraditya303 merged commit7f155f9 intopython:mainOct 9, 2025
117 checks passed
@kumaraditya303kumaraditya303 added the needs backport to 3.14bugs and security fixes labelOct 9, 2025
@miss-islington-app
Copy link

Thanks@yoney for the PR, and@kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

@miss-islington-app
Copy link

Sorry,@yoney and@kumaraditya303, I could not cleanly backport this to3.14 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 7f155f9c46e2dd7dec5e12ebec3323dfd95fe1f0 3.14

kumaraditya303 pushed a commit to kumaraditya303/cpython that referenced this pull requestOct 9, 2025
(cherry picked from commit7f155f9)Co-authored-by: Alper <alperyoney@fb.com>
@bedevere-app
Copy link

GH-139825 is a backport of this pull request to the3.14 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.14bugs and security fixes labelOct 9, 2025
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotAMD64 FreeBSD Refleaks 3.x (tier-3) has failed when building commit7f155f9.

What do you need to do:

  1. Don't panic.
  2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/1613/builds/2130) and take a look at the build logs.
  4. Check if the failure is related to this commit (7f155f9) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/1613/builds/2130

Test leaking resources:

  • test_events: references
  • test_events: memory blocks

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):  File"/buildbot/buildarea/3.x.ware-freebsd.refleak/build/Lib/test/support/__init__.py", line847, ingc_collect    gc.collect()~~~~~~~~~~^^ResourceWarning:unclosed <socket.socket fd=9, family=2, type=1, proto=6, laddr=('127.0.0.1', 38818), raddr=('127.0.0.1', 38819)>Task was destroyed but it is pending!task:<Task pending name='Task-3140' coro=<BaseSelectorEventLoop._accept_connection2() done, defined at /buildbot/buildarea/3.x.ware-freebsd.refleak/build/Lib/asyncio/selector_events.py:217> wait_for=<Future pending cb=[Task.task_wakeup()]>>Warning -- Unraisable exceptionException ignored while calling deallocator <function _SelectorTransport.__del__ at 0x837dda750>:Traceback (most recent call last):  File"/buildbot/buildarea/3.x.ware-freebsd.refleak/build/Lib/asyncio/selector_events.py", line873, in__del__    _warn(f"unclosed transport{self!r}",ResourceWarning,source=self)~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ResourceWarning:unclosed transport <_SelectorSocketTransport closing fd=9>kTraceback (most recent call last):  File"/buildbot/buildarea/3.x.ware-freebsd.refleak/build/Lib/test/support/__init__.py", line847, ingc_collect    gc.collect()~~~~~~~~~~^^ResourceWarning:unclosed <socket.socket fd=9, family=2, type=1, proto=6, laddr=('127.0.0.1', 55024), raddr=('127.0.0.1', 55025)>Task was destroyed but it is pending!task:<Task pending name='Task-1740' coro=<BaseSelectorEventLoop._accept_connection2() done, defined at /buildbot/buildarea/3.x.ware-freebsd.refleak/build/Lib/asyncio/selector_events.py:217> wait_for=<Future pending cb=[Task.task_wakeup()]>>Warning -- Unraisable exceptionException ignored while calling deallocator <function _SelectorTransport.__del__ at 0x841981250>:Traceback (most recent call last):  File"/buildbot/buildarea/3.x.ware-freebsd.refleak/build/Lib/asyncio/selector_events.py", line873, in__del__    _warn(f"unclosed transport{self!r}",ResourceWarning,source=self)~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ResourceWarning:unclosed transport <_SelectorSocketTransport closing fd=9>k

w-hsiung pushed a commit to w-hsiung/cpython that referenced this pull requestOct 9, 2025
…) (python#139825)* [3.14]pythongh-116738: make `mmap` module thread-safe (pythonGH-139237)(cherry picked from commit7f155f9)Co-authored-by: Alper <alperyoney@fb.com>
@yoneyyoney deleted the ft_mmap branchOctober 19, 2025 03:02
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@ZeroIntensityZeroIntensityZeroIntensity left review comments

@vstinnervstinnervstinner approved these changes

@kumaraditya303kumaraditya303kumaraditya303 approved these changes

Assignees

@kumaraditya303kumaraditya303

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@yoney@corona10@ZeroIntensity@bedevere-bot@vstinner@kumaraditya303
[8]ページ先頭
©2009-2026 Movatter.jp