gh-135410: Use a critical section around StringIO.__next__#135412
gh-135410: Use a critical section around StringIO.__next__#135412kumaraditya303 merged 3 commits intopython:mainpython/cpython:mainfrom
StringIO.__next__#135412Conversation
|
Let's consider the following options.
|
|
Yeah, I totally agree on that. There was an issue similar to this a few weeks ago, where a |
|
I am fine with if this change will not regress overall performance. But if the object is shared by multiple threads user should care about the correctness if the object itself does not gurentee it. |
vstinner
left a comment
There was a problem hiding this comment.
LGTM.
Without the fix, the test fails randomly with:
FAIL: test_concurrent_use (test.test_memoryio.PyStringIOPickleTest.test_concurrent_use)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/vstinner/python/main/Lib/test/test_memoryio.py", line 742, in test_concurrent_use
self.assertIsNone(cm.exc_value)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
AssertionError: UnboundLocalError("cannot access local variable 'dec_flags' where it is not associated with a value") is not None
So the test works as expected!
Currently, the doc says nothing about io.StringIO: https://docs.python.org/dev/library/io.html#multi-threading |
|
Thanks @ZeroIntensity for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14. |
|
Thanks @ZeroIntensity for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13. |
…ythonGH-135412) (cherry picked from commit e6c3039) Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
|
Sorry, @ZeroIntensity and @kumaraditya303, I could not cleanly backport this to |
|
GH-135425 is a backport of this pull request to the 3.14 branch. |
|
|
|
|
Those buildbot failures look related. I'll quickly investigate and if I can't figure it out in the next half an hour or so, I'll put up a revert. |
|
IMO this change was merged too quickly and I suggest to revert it.
I suggest to revert the two changes (main and 3.14 branches) and spend more time to design this fix. I don't think that there is any urgency to fix this issue. |
|
Sorry for the hassle everyone! I didn't get a chance to reply to any comments before it was merged. I'll put up a revert while we discuss this. |
…xt__` (python#135412)" This reverts commit e6c3039.
…xt__` (pythonGH-135412)" (pythonGH-135439) This reverts commit e6c3039. (cherry picked from commit 7343135) Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
…xt__` (python#135412)" (python#135439) This reverts commit e6c3039.
…xt__` (python#135412)" (python#135439) This reverts commit e6c3039.
…xt__` (python#135412)" (python#135439) This reverts commit e6c3039.
…xt__` (python#135412)" (python#135439) This reverts commit e6c3039.
I'm generally not a fan of adding locks around
__next__, because concurrent iteration isn't generally a real use case, butreadlinescalls into__next__.StringIOmethods in threads on free-threading debug build #135410