It's not clear when try_clone calls can fail

[achanda]

Some types have a try_clone methods that returns Result<T>. From the documentation, it is not clear under what conditions can this call fail. Types that implement it are

https://doc.rust-lang.org/std/?search=try_clone

[cuviper]

The error conditions are OS-dependent, e.g. from Windows DuplicateHandle or Posix dup (or really fcntl F_DUPFD_CLOEXEC).

[retep998]

Because try_clone creates a new handle or file descriptor, any sort of resource exhaustion which prevents another handle or file descriptor from being created can cause try_clone to fail.

[DevQps]

@steveklabnik I guess this issue raises about the same questions as #40322 namely: "Should we be documenting platform specific behavior and error codes)?" Maybe we should ping the libs team for this one as well?

[pocesar]

for windows specifically for TcpStream:

Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function.

[DevQps]

@steveklabnik What do you think we should do with this? Personally I find it quite clear from the context that these methods can fail (since they deal with OS primitives like sockets and files). But adding extra information in what kind of contexts they could fail would mean adding platform-specific cases. Do you think that we can close this? Or do you believe we should append something to the currently existing docs?

[steveklabnik]

Given this comment, I believe we should close this issue.