Re: Per-descriptor state

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 30 Apr 2023 05:25:41 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <ZE371Uhm+zXvnBUl%netbsd.org@localhost>

  | Close-on-fork is apparently either coming or already here, not sure
  | which, but it's also per-descriptor.

We don't have it, but it will be in Posix-8.   Largely inspired by the
needs of threaded programs (without lots of critical sections, one cannot
otherwise open anything if another thread might fork, there's no
way to avoid race conditions, hence O_CLOFORK on open ... not sure if
anyone has thought of a way to add it to socket() - that doesn't look
to be trivial, though it might be possible to abuse one of the params
it has - probably domain - and add flags in upper bits ... while having
it able to be set/reset via fcntl is useful, to work, it needs to be
able to be set atomically with the operation that creates the fd, and
having it default "on", which would work, would break almost all existing
non-trivial code).

  | But I kind of think it'd be preferable to make a way to
  | clone a second independent struct file for the same socket than to
  | start mucking with per-descriptor state.

When I saw mouse's message, I was thinking the exact same thing,
and it should be easy to extend dup3() to make that possible - however
I'm not sure what effects that might have on the semantics of sockets
(what assumptions the current code might make about there being only
one struct file, with all it contains, for a socket).

kre