I do not like this.

1. It is too complicated and verbose.
2. There is still a chance for race condition, if between pushing self.handler on the stack and calling the corresponding OS function, the handler was closed and a new file was open that reuses the same fileno.

I have not tested the code on Windows yet, very likely more try/exept or return code checks should be added in Windows specific code.

The more I look at this, the more I dislike it. I do not see how is it possible to safely close a file descriptor on other thread without locking. Making Connection and PipeConnection truly thread-safe in a task on completely different level.

I opened #109780 instead.

Making Connection and PipeConnection truly thread-safe in a task on completely different level.

Maybe we should just give up and document that they are not thread-safe.

I recall that I did that once on some asyncio classes.