Cloned sockets are inherited by child processes on windows #70719
Labels
A-io
Area: `std::io`, `std::fs`, `std::net` and `std::path`
A-process
Area: `std::process` and `std::env`
C-bug
Category: This is a bug.
O-windows
Operating system: Windows
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Given this test code running on Windows 10 compiled with rustc 1.41.0:
I would expect UDP port 9999 to no longer be listening after the code terminates and I would expect both
socket1
andsocket2
to reportfalse
on the state of theirHANDLE_FLAG_INHERIT
.Instead port 9999 remains in a listening state until I close the spawned child process
notepad
andsocket2
shows that itsHANDLE_FLAG_INHERIT
is set.This appears to have been introduced in rust 1.38.0 via PR #60260 which now sets the
WSA_FLAG_NO_HANDLE_INHERIT
inWSASocketW
instead of explicitly clearing theHANDLE_FLAG_INHERIT
withSetHandleInformation
. Just to confirm, I have compiled this againstnightly-2019-07-26-x86_64-pc-windows-msvc
(before PR) andnightly-2019-07-27-x86_64-pc-windows-msvc
(after PR) and this code behaves as expected before the PR.On the surface that PR looks solid and I would totally expect it to work. However it seems (surprisingly) that setting the
WSA_FLAG_NO_HANDLE_INHERIT
flag on a duplicated socket is not effective. I have googled until I could google no longer and alas have found no mention of this behavior.As a workaround, doing something like:
fixes my use case.
Perhaps the correct fix is for
duplicate
to callset_no_inherit
unless it is a UWP app. However I would love it if someone had deeper knowledge as to why this behavior is as it is.The text was updated successfully, but these errors were encountered: