You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Socket#close_on_exec? and FileDescriptor#close_on_exec? both have a fixed value of false on Windows. This was originally introduced in #5339 for file descriptors, and since #14634 also applies to sockets (before that patch, it didn't even compile).
The concept of close_on_exec only exists on Unix systems due to the fork/exec mechanism. This is not a thing on Windows.
We still need to somehow implement the API on Windows, hence it has a fixed value. Though the choice to make it false is unexpected to me.
The underlying concept is about whether child processes inherit a file descriptor (or socket). close_on_exec == true means the file descriptor is closed on exec and child process won't inherit. close_on_exec == false means the opposite: the file descriptor is not closed on exec and child processes inherit.
On Windows, child processes don't inherit handles from the parent process by default. Following from that I would assume close_on_exec == true should hold on Windows.
The inheritance behaviour of IO::FileDescriptor and Socket on Windows is equivalent to the default on Unix systems, which is close_on_exec == true.
We could consider renaming the property to a more abstract name like inherited_by_child_processes to move away from platform-specific terminology and make this equivalence more visible.
Note, there are ways to enable inheritance for handles in Windows as well: https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873
We might want to look into implementing that in the future. It's a bit of a rabbit hole, though. A proper, thread-safe implementation as noted in this article needs to specifiy inheritable handles at process creation. So this would rather be an option for Process.new than a property on IO::FileDescriptor and Socket.
I figure similar issues as mentioned for inheritance on Windows apply to Unix systems as well. So perhaps it might really be a good idea to introduce a new mechanism which operates on process creation instead of a global configuration per file descriptor.
The text was updated successfully, but these errors were encountered:
Oh, passing the inheritable file descriptors to Process.new sounds good: Windows works this way, while on UNIX we could set FD_CLOEXEC after fork and before exec, so we'd pass the file descriptors to the actual sub-process, without leaking to any other sub-process another thread happens to spawn in parallel, nor using any lock. Nice!
Then we could deprecate the UNIX specific #close_on_exec? and #close_on_exec= 👍
Socket#close_on_exec?
andFileDescriptor#close_on_exec?
both have a fixed value offalse
on Windows. This was originally introduced in #5339 for file descriptors, and since #14634 also applies to sockets (before that patch, it didn't even compile).The concept of
close_on_exec
only exists on Unix systems due to the fork/exec mechanism. This is not a thing on Windows.We still need to somehow implement the API on Windows, hence it has a fixed value. Though the choice to make it
false
is unexpected to me.The underlying concept is about whether child processes inherit a file descriptor (or socket).
close_on_exec == true
means the file descriptor is closed on exec and child process won't inherit.close_on_exec == false
means the opposite: the file descriptor is not closed on exec and child processes inherit.On Windows, child processes don't inherit handles from the parent process by default. Following from that I would assume
close_on_exec == true
should hold on Windows.The inheritance behaviour of
IO::FileDescriptor
andSocket
on Windows is equivalent to the default on Unix systems, which isclose_on_exec == true
.We could consider renaming the property to a more abstract name like
inherited_by_child_processes
to move away from platform-specific terminology and make this equivalence more visible.Note, there are ways to enable inheritance for handles in Windows as well: https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873
We might want to look into implementing that in the future. It's a bit of a rabbit hole, though. A proper, thread-safe implementation as noted in this article needs to specifiy inheritable handles at process creation. So this would rather be an option for
Process.new
than a property onIO::FileDescriptor
andSocket
.I figure similar issues as mentioned for inheritance on Windows apply to Unix systems as well. So perhaps it might really be a good idea to introduce a new mechanism which operates on process creation instead of a global configuration per file descriptor.
The text was updated successfully, but these errors were encountered: