On Fri, Apr 21, 2023 at 12:14 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Sergey Bugaev, le lun. 17 avril 2023 16:38:59 +0300, a ecrit: > > The only valid flag defined here is FD_CLOEXEC. It is of no concern to > > the receiving process whether or not the sender process wants to close > > its copy of sent file descriptor upon exec, > > Ok, but couldn't there be some flags that we could want to transfer, in > the future?
Unlikely -- it's been years (I don't know how old FD_CLOEXEC is exactly, but it surely predates O_CLOEXEC by many years) and AFAIK nobody came up with any ideas for more fd flags, other than FD_CLOFORK, but that wouldn't be transferable either. And the whole idea of fd flags (as opposed to flags applied to the open file itself, the peropen in Hurd terms, like O_NONBLOCK and O_ASYNC) is that they apply to that single file descriptor, and are not carried over when it's dup'ed. sendmsg+recvmsg is like a remote dup in this sense. > I'd better keep the infrastructure, even if it is not > actually useful for now. So that people who end up needing something see > that passing it is already supported. I understand, but also it's not like there's a lot of infrastructure that I'm removing here. You could think of it that way: the infrastructure for passing an integer value along with the port is still there, but currently no valid flags for it are defined, and so 0 is always used. We could spell it as fds[i] = descriptor->flags & ~FD_CLOEXEC; if you would prefer; but that would still always evaluate to 0 (but the compiler wouldn't be aware and would generate the extra instructions). Sergey
