On Sun, Apr 30, 2023 at 10:50:51PM +0700, Robert Elz wrote: > Date: Sun, 30 Apr 2023 05:25:41 +0000 > From: David Holland <dholland-t...@netbsd.org> > Message-ID: <ze371uhm+zxvn...@netbsd.org> > > | 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).
Given that the trend is to just add extra calls with flags arguments without even pausing to consider, I'd be surprised if nobody's banged out a socket4() yet. > | 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 If we were to add such a thing it should be called something else, not dup, because it's a fundamentally different operation from dup and we don't need people confusing them. > - 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). Indeed :-| -- David A. Holland dholl...@netbsd.org