Use critical sections to protect I/O objects (in `--disable-gil` builds)

[colesbury]

Feature or enhancement

The I/O objects, like io.BufferedIOBase, io.TextIOWrapper, and io.StringIO have 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_SECTION manually.

For context, here are the similar modifications in the nogil-3.12 fork, but the implementation in CPython 3.13 will be a bit different (no need for extra locks, use the syntax from #111903):

• colesbury/nogil-3.12@ffade9d6f6 (PR by @Mayuresh16)
• colesbury/nogil-3.12@5b83c16dcd (PR by @aisk)
• colesbury/nogil-3.12@6323ca60f9 (PR by @aisk)

Linked PRs

• gh-111965: Using critical sections to make io.StringIO thread safe. #112116
• gh-111965: Use critical sections to make io.TextIOWrapper thread safe #112193
• gh-111965: Use critical sections to make io.BufferedIOBase and its related classes thread safe #112298

[aisk]

The TextIOBase should 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 to TextIOWrapper? @colesbury

[colesbury]

Yes, thanks, it should say TextIOWrapper. I've edited the issue.

[sobolevn]

Sorry, what about _pyio?

[colesbury]

@sobolevn, any specific concerns? I didn't see anything that looked like it required locking, but I may have missed something.

[sobolevn]

No, no specific questions :)
I hoe that our new tests for threaded IO will catch any potential differences between two implementations 👍

[Mayuresh16]

@colesbury Hi, I would like to give it a try for io.BufferedXXX implementation and will be happy to start my first open-source contribution with CPython based on my knowledge and understanding of the tools. 😅