tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Per-descriptor state



On Sun, Apr 30, 2023 at 09:44:49AM -0400, Mouse wrote:
 > > Close-on-fork is apparently either coming or already here, not sure
 > > which, but it's also per-descriptor.
 > 
 > I should probably add that here, then, though use cases will likely be
 > rare.  I can think of only one program I wrote where it'd be useful; I
 > created a "close these fds post-fork" data structure internally.

I can't think of any at all; to begin with it's limited to forks that
don't exec, and unless just using it for convenience as you're
probably suggesting, it only applies when also using threads, and if
one's using threads why is one also using forks? So it seems like it's
limited to badly designed libraries that want to fork behind the
caller's back instead of setting up their forks at initialization
time. Or something.

 > > The thing is, per-descriptor state is a mess and it shouldn't be
 > > allowed to proliferate.  The reason: the descriptor is an array
 > > index.  There's plenty of room to store stuff in the object it looks
 > > up (that is, struct file) but storing stuff on the key side of the
 > > array is a problem.
 > 
 > (References to -current here really mean "filedesc.h 1.70 according to
 > cvsweb.netbsd.org".)
 >
 > [...]

I had forgotten how much crap we'd added on behalf of the silly broken
close scheme. So all those costs have been paid already. :-|

 > > (Then there's also another issue, which is that in nearly all cases
 > > nonblocking I/O is a workaround for interface bugs, e.g. nonblocking
 > > accept or open of dialout modem devices, or for structural problems
 > > in software that also needs to use the same file handle, like your
 > > original problem with curses. In the long run it's probably better to
 > > kill off the reasons to want to use nonblocking I/O at all.)
 > 
 > And replace nbio with...what?  Multiple threads doing blocking calls?
 > Or do you think everything should be nonblocking by default, with
 > blocking behaviour implemented userland-side?  Or am I completely
 > misinterpreting somehow?

select?

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index