Use $NOCANCEL variants of APIs on apple platforms

[hamarb123]

Fixes #117299.
Affects the following APIs: #117299 (comment).

[hamarb123]

Note: there's one place where we're not currently treating EINTR from close as don't repeat that we may want to change:

• runtime/src/coreclr/pal/src/sharedmemory/sharedmemory.cpp

  Line 589 in 9e5e6aa

  closeResult = close(fileDescriptor);

And we could also optionally mark EINTR on close as success in a few places on apple platforms now (e.g., SystemNative_Close) (and also linux according to https://issues.chromium.org/issues/41033222 (source from linus), as it has this behaviour built into normal close), as the close$NOCANCEL version guarantees it isn't leaked when EINTR is returned.

Please lmk what I should do with these.

[jkotas]

there's one place where we're not currently treating EINTR from close as don't repeat that we may want to change:

I think so.

And we could also optionally mark EINTR on close as success in a few places on apple platforms now

Is there any place where it makes a difference? We seem to be ignoring EINTR returned by close everywhere.

I have noticed that t_lastCloseErrorInfo in SafeFileHandle.Unix.cs looks like a dead code. I think it can be deleted.

[hamarb123]

Is there any place where it makes a difference? We seem to be ignoring EINTR returned by close everywhere.

Btw, there's 2 places where we're already doing what I'm proposing, and treating EINTR as success:

• runtime/src/native/libs/System.Native/pal_networking.c

  Line 3110 in 9e5e6aa

  return err == 0 || (err < 0 && errno == EINTR) ? Error_SUCCESS : SystemNative_ConvertErrorPlatformToPal(errno);

• runtime/src/native/libs/System.Native/pal_networking.c

  Line 3265 in 9e5e6aa

  return err == 0 || (err < 0 && errno == EINTR) ? Error_SUCCESS : SystemNative_ConvertErrorPlatformToPal(errno);

There's a handful of places where we're treating it as a failure, but I'm not sure if they actually matter as I'm not familiar with how the return value is used:

• runtime/src/libraries/System.IO.Pipes/src/Microsoft/Win32/SafeHandles/SafePipeHandle.Unix.cs

  Line 64 in 9e5e6aa

  Interop.Sys.Close(handle) == 0 :

• runtime/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SafeSocketHandle.Unix.cs

  Line 299 in 9e5e6aa

  if (Interop.Sys.Close(handle) != 0)

• runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.Unix.cs

  Line 163 in 9e5e6aa

  return result == 0;

• runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SafeSerialDeviceHandle.Unix.cs

  Line 44 in 9e5e6aa

  return result == 0;

• runtime/src/coreclr/pal/src/misc/perfjitdump.cpp

  Line 358 in 9e5e6aa

  if (result == -1)

Imo, we should adjust one set of the above to be the same as the other - whichever one is preferred - ignoring EINTR should be correct to do on Apple platforms with the new define & Linux - what other platforms do we support where it may be a concern?

And here's actually another spot where we're retrying that I'll fix up along with the sharedmemory.cpp one:

• runtime/src/native/eventpipe/ds-ipc-pal-socket.c

  Line 425 in 9e5e6aa

  } while (ipc_retry_syscall (result_close));

[jkotas]

There's a handful of places where we're treating it as a failure, but I'm not sure if they actually matter as I'm not familiar with how the return value is used:

As far as I can tell, the return value always ends up being ignored for the managed ones in your list. I guess we can ignore EINTR in SystemNative_Close to make it easier to follow.

runtime/src/coreclr/pal/src/misc/perfjitdump.cpp should be fixed to ignore the return value from close.

what other platforms do we support where it may be a concern?

I believe HP-UX is the only platform where it is correct to retry when close return EINTR. We do not support HP-UX. So it can be ignored unconditionally.