Repository navigation
Use critical sections to protect I/O objects (in --disable-gil builds) #111965
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancement3.13only security fixesonly security fixes
on Nov 10, 2023 The
TextIOBaseshould be a base class and it's methods is just raise exceptions, so I think it dosen't need critical section protect. Is it a typo toTextIOWrapper? @colesburyYes, thanks, it should say
TextIOWrapper. I've edited the issue.Sorry, what about
_pyio?@sobolevn, any specific concerns? I didn't see anything that looked like it required locking, but I may have missed something.
Reacted by sobolevnNo, no specific questions :)
I hoe that our new tests for threaded IO will catch any potential differences between two implementations 👍@colesbury Hi, I would like to give it a try for
io.BufferedXXXimplementation and will be happy to start my first open-source contribution with CPython based on my knowledge and understanding of the tools. 😅- added a commit that references this issue
on Nov 22, 2023 Looks like it is done! 🎉
Reacted by Sam Gross, An Long and Mayuresh Kedari
Feature or enhancement
The I/O objects, like
io.BufferedIOBase,io.TextIOWrapper, andio.StringIOhave internal state that would not be thread-safe without the GIL.We should be able to mostly use Argument Clinic's (AC) support for "critical sections" to guard methods on these objects. For operations that don't use AC, we can either convert them to use AC or write the
Py_BEGIN_CRITICAL_SECTION/Py_END_CRITICAL_SECTIONmanually.For context, here are the similar modifications in the
nogil-3.12fork, but the implementation in CPython 3.13 will be a bit different (no need for extra locks, use the syntax from #111903):Linked PRs
io.StringIOthread safe. #112116