internal/poll: avoid race between execIO and DisassociateIOCP
This is a step towards deferring adding the handle to IOCP until the
first IO operation.
There is a small race windows between execIO and DisassociateIOCP where
execIO checks if the fd is disassociated before passing the operation to
the OS. DisassociateIOCP can set the disassociated flag right after that
check but before Windows started processing the IO operation. Once
Windows takes over, the race doesn't matter anymore because Windows
doesn't allow disassociating a handle that has pending IO operations.
If that still hasn't happened, an overlapped IO operation will start
assuming the they can be waited using the Go runtime IOCP, which is
wrong due to the disassociation, leading to undefined behavior.
Fix that race by trying to take a write/read lock in DisassociateIOCP
before setting the disassociated flag, but failing if there is an
ongoing execIO operation so that DisassociateIOCP doesn't block
indefinitely waiting for execIO to finish.
For #76391
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-amd64-race
Change-Id: Iec265fa1900383aace50051d2be750bc76aa0944
Reviewed-on: https://go-review.googlesource.com/c/go/+/741020
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>