As of JRuby 9.1.15, there are several types of streams that cannot be set close-on-exec:

1. Java channels that cannot be reflectively unpacked, since we can't get at the file descriptor.
   This means all streams when we can't use native IO (e.g. on Windows currently) and reflection is limited (such as on secured environments or stock Java 9). However my reading of OpenJDK source indicates they are already setting cloexec for most (all?) JDK-provided streams.
   Note that third-party libraries may have their own streams that we do not know how to unwrap.
2. Streams that have no associated file descriptor, like opaque ReadableChannel or OutputStream wrappers. This is not a large concern because non-fd streams have no fd themselves to cloexec. If they eventually wrap a fd-backed stream, then ideally it's JDK-provided (and so already cloexec) or it handles cloexec itself in some other way.

There are two sides to this feature: whether streams get set cloexec by default, and whether it's possible to change that cloexec bit.

I believe currently all our streams should be getting set to cloexec by default, since the JDK appears to do it for its streams and we are now doing it for our native streams (after fixes to #4858).

As much as possible we should try to support querying cloexec, or a reasonable fallback, for all cases. Currently this is implemented by assuming non-unwrappable streams are already cloexec, since that usually means they're rooted at a JVM stream. For real native streams we can obviously read the cloexec bit.

It will not be possible to change cloexec across all stream types. If we have a stream we can't unwrap and that does not provide a way to change cloexec, we will be unable to change it. The fixes for #4858 include a warning when someone's trying to set cloexec on a stream that can't modify cloexec. We can mitigate some of these cases if native is available; for example, if reflection is disabled but native IO is available we should prefer a native pipe to the JDK-provided pipe (arguably we should always prefer a native pipe for native IO).

At the very least we should have decent documentation and warnings when we're unable to fully support cloexec on a given stream.