| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
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>
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
@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.
Sorry, something went wrong.
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
This reverts commit 78241a8.
| if (key == NULL) { | ||
| si->si_set = NULL; | ||
| /* exhausted */ | ||
| Py_DECREF(so); |
There was a problem hiding this comment.
Can you move the decref to the section
/* exhausted */
si->si_pos = -1;
si->len = 0;
?
Sorry, something went wrong.
There was a problem hiding this comment.
I’d prefer not to move the Py_DECREF into the Py_BEGIN_CRITICAL_SECTION block.
Sorry, something went wrong.
There was a problem hiding this comment.
We went through several iterations, but currently the PR:
Remaining suggestions are about the style, not about the actual implementation so I am approving.
Sorry, something went wrong.
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
| #ifdef Py_GIL_DISABLED | ||
| Py_BEGIN_CRITICAL_SECTION2(self, so); | ||
| #else | ||
| Py_BEGIN_CRITICAL_SECTION(so); |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
|
Hi @colesbury @kumaraditya303 — a gentle ping on this PR. I think all the review points have now been addressed:
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! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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