GeezerVison

We should not get EBADF. We should just not call functions on closed handle. If we land in this case, we failed badly before, no?

How can we know that it was closed in other thread without using locks?

You can get EBADF in the following scenario:

• Thread A reads self._handle and puts in on the stack.
• Thread B closes it.
• Thread A calls function with an already closed file descriptor on the stack.
• That function fails with EBADF errno.

It is the bast case. The worst case is:

• Thread A reads self._handle and puts in on the stack.
• Thread B closes it.
• Thread B or C opens a new file descriptor which reuses the same integer value.
• Thread A calls function with a file descriptor which now refers to unrelated file or socket.
• Unpredictable consequences.

Would it be possible to split this change in two parts? Keep this change for _check_closed() change which now raises BrokenPipeError, and you changes around close(): these ones look straightforward are correct. But write a separated PR to add these try/except?

I dislike these try/except. If there is a risk to land into EBADF case with the current code, maybe some kind of locking is needed to not call the Windows API with a handle, while another thread call close() which invalidates the handle.