Do not inherit socket handles

[Tratcher]

#2789 If the accept socket's handle gets inherited by child processes, then it's not fully closed until all of the child processes are closed.

Connected sockets don't seem to be affected.

[halter73]

Might as well using sh instead of bash since the former is required by POSIX even if it happens to be bash.

[Tratcher]

@dotnet-bot test Windows Debug x64 Build
@dotnet-bot test Windows Release x64 Build

[Tratcher]

@dotnet-bot test OSX 10.12 Debug x64 Build
@dotnet-bot test OSX 10.12 Release x64 Build

[Tratcher]

Hm, VI works on linux but not mac. I may call that good enough for this test and skip Mac.

[Tratcher]

@dotnet-bot test Windows Debug x64 Build

[halter73]

Are we sure handle inheritance isn't an issue on macOS?

[Tratcher]

Yes, the corefx issue was clear that this is only an issue for Windows.

[halter73]

Nit: HandleInheritanceTests

[Tratcher]

Hmm, the Listen test consistently fails on Mac Sockets, and the Connection test is flaky on Windows Libuv.
@dotnet-bot test OSX 10.12 Debug Build
@dotnet-bot test OSX 10.12 Release Build
@dotnet-bot test Windows Debug x64 Build
@dotnet-bot test Windows Release x64 Build

[Tratcher]

Ok, I tracked down the Mac issue.

The linux equivilent of what we did on windows is https://legacy.python.org/dev/peps/pep-0433/#socket-socket
But these APIs doen't exist on MacOS, or at least didn't exist a few years ago when other frameworks were dealing with this.
rust-lang/rust#24237
https://github.com/libuv/libuv/blob/81c77427afb39b6fa6c0ecffdc1c1e2b3dde7aea/src/unix/core.c#L417-L424
Regardless, those workarounds primarily pass a flag to the socket constructor which we cannot do.

I'm going to go back to skipping this test on Mac since we don't have a way to fix it there. Still need to figure out what's flaky with Windows Libuv.

[tmds]

On mac and Linux corefx does this by default: https://github.com/dotnet/corefx/blob/master/src/Native/Unix/System.Native/pal_networking.c#L1292-L1307

Perhaps corefx should do this for Windows sockets too?
The best implementation is when you can pass the flag when you create the socket. Otherwise there is a race-condition when someone creates a child between socket construction and setting the flag.

[Tratcher]

@tmds what's the expected behavior of FD_CLOEXEC? From the name it sounds like close-on-process-exit. It isn't working in my Mac tests (currently disabled). Note my tests don't close the parent process, only the socket in the parent process.

[tmds]

Cloexec causes the handle not to be inherited by child processes. Exec refers to the system call to execute a program. When the child process execs, that handle is closed for the child.

[Tratcher]

When the child process execs, that handle is closed for the child.

Ah, but the duplicated handle remains open in the parent process even if I close the original Socket? That would explain why it's not working on Mac, but doesn't explain why Linux is working.

[tmds]

The listen socket is not duplicated to the children, so when the parent closes it, the server is no longer accepting connections. That explains why it works on Linux. I don't know why it doesn't work on Mac. Mac has limited cloexec apis compared to Linux. Maybe some things are not really supported.

For Windows, I think it makes sense that corefx sockets also by default would not be inherited by children.

[Tratcher]

Updated. I've removed the flaky connected socket test, we're not modifying that scenario and the flakiness seems to be unrelated. The listen test is disabled for Mac.

Note this is considered to be a temporary mitigation. I'll follow up with corefx for a more comprehensive xplat fix in 3.0.

Updated