FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

gh-144356: Make set iterator `__length_hint__` and `iternext` race-safe under no-gil by hyongtao-code · Pull Request #144357 · python/cpython · GitHub

Repository navigation

gh-144356: Make set iterator __length_hint__ and iternext race-safe under no-gil - #144357

Open
hyongtao-code wants to merge 24 commits into
python:mainfrom
hyongtao-code:fix-data-race
Open

hyongtao-code wants to merge 24 commits into
python:mainfrom
hyongtao-code:fix-data-race

Conversation

hyongtao-code commented Jan 31, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Long log:

In free-threaded builds, setiter_len() and setiter_iternext() could race with concurrent set mutation and iterator exhaustion.

We now serialize operations on the iterator itself (and keep the set stable) using a critical section, and ensure the iterator’s exhaustion state is handled consistently.

The non-free-threaded build keeps the existing semantics. Add free-threading-style concurrency tests (similar to the itertools FT tests) to exercise __length_hint__ and iternext exhaustion under concurrent execution.

setiter_len() was reading so->used without atomic access while concurrent
mutations update it atomically under Py_GIL_DISABLED.

In free-threaded builds, setiter_len() could race with concurrent set
mutation and iterator exhaustion.

Use an atomic load for so->used to avoid a data race. This preserves the
existing semantics of __length_hint__ while making the access thread-safe.

Signed-off-by: Yongtao Huang yongtaoh2022@gmail.com

setiter_len() was reading so->used without atomic access while concurrent
mutations update it atomically under Py_GIL_DISABLED.

Use an atomic load for so->used to avoid a data race. This preserves the
existing semantics of __length_hint__ while making the access thread-safe.

Signed-off-by: Yongtao Huang <yongtaoh2022@gmail.com>
Comment thread Objects/setobject.c
hyongtao-code changed the title gh-144356: fix data race in setiter_len() under no-gil gh-144356: Avoid races when computing set_iterator.__length_hint__ under no-gil Feb 1, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the review. I’ve decided to address both issues in this PR. I also added a corresponding test case for the issue you pointed out.

Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated

eendebakpt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I left some more review comments. I think we can get this right, but a simpler approach here would be to put a critical section on the set iterator itself.

Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated

Copy link
Copy Markdown
Contributor Author

put a critical section on the set iterator

Thanks for the suggestion. I simplified the implementation by protecting both the iterator and the set with Py_BEGIN_CRITICAL_SECTION2(self, so), so concurrent use of the same iterator is properly serialized. This keeps the logic aligned with other iterators and avoids the races.

It looks like there is an unrelated flaky test case.

eendebakpt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

@hyongtao-code Thanks for your work on this! The core idea of the PR has shifted a bit, which is why I have some more review comments, but we are getting closer I believe.

Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
hyongtao-code and others added 2 commits February 9, 2026 19:09
hyongtao-code changed the title gh-144356: Avoid races when computing set_iterator.__length_hint__ under no-gil gh-144356: Make set iterator __length_hint__ and iternext race-safe under no-gil Feb 10, 2026
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c Outdated
Comment thread Objects/setobject.c
if (key == NULL) {
si->si_set = NULL;
/* exhausted */
Py_DECREF(so);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Can you move the decref to the section

       /* exhausted */
        si->si_pos = -1;
        si->len = 0;

?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I’d prefer not to move the Py_DECREF into the Py_BEGIN_CRITICAL_SECTION block.

eendebakpt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

We went through several iterations, but currently the PR:

  • Adds free-threading tests for the behavior of set iterators
  • Makes the set iterator safe in the FT build by using locks and not freeing the underlying set

Remaining suggestions are about the style, not about the actual implementation so I am approving.

hyongtao-code and others added 3 commits February 13, 2026 22:22
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
Comment thread Objects/setobject.c Outdated
#ifdef Py_GIL_DISABLED
Py_BEGIN_CRITICAL_SECTION2(self, so);
#else
Py_BEGIN_CRITICAL_SECTION(so);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

On normal builds Py_BEGIN_CRITICAL_SECTION is a no-op, you either want Py_BEGIN_CRITICAL_SECTION or Py_BEGIN_CRITICAL_SECTION2, not both.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Hi, thanks for your review. I switched this to always use Py_BEGIN_CRITICAL_SECTION2(self, so) / Py_END_CRITICAL_SECTION2().

The remaining #ifdef Py_GIL_DISABLED around the done label is a bit awkward, but it preserves the existing control flow.

github-actions Bot commented May 5, 2026

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

github-actions Bot added the stale Stale PR or inactive for long period of time. label May 5, 2026

weixlu commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Hi @colesbury @kumaraditya303 — a gentle ping on this PR. I think all the review points have now been addressed:

  • colesbury : si->si_set is no longer cleared on exhaustion.
  • kumaraditya303: the mixed Py_BEGIN_CRITICAL_SECTION / Py_BEGIN_CRITICAL_SECTION2 usage is fixed.

Would you mind taking another look?

On a related note: I found other builtin iterators have similar race issues (discussed here) — I'm planning to send follow-up fixes.

Thanks!

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants


Back | FazBrowse Home | New Git URL