Re: Per-descriptor state

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Apr 30, 2023 at 12:49:03AM -0400, Mouse wrote:
 > This is pushing towards making it per-descriptor state.  At present,
 > the versions I have don't have anything but close-on-exec as true
 > per-descriptor state.  A quick look at 9.1 and cvsweb.netbsd.org
 > (which, mirabilu visu, actually works for me, unlike www.netbsd.org and
 > mail-index.netbsd.org) sys/sys/filedesc.h makes me think that that's
 > true of them as well.

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

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. For a couple bits you can mask them off from the pointer
(though even that's abusive); more than that and suddenly you need to
double the size of the fdtable so it contains an extra machine word
for random state bits as well as the pointer to the struct file.
Granted, it's not like this is going to make any machine (that can run
Unix at all) tip over from KVA exhaustion, but it's untidy, messy,
wasteful, and generally offensive to cleanliness.

In general I think there is very little reason to have per-descriptor
(rather than per-open) state and the only really valid use cases are
those that pertain specifically to individual descriptor numbers,
which in turn is pretty much limited to close behavior like
close-on-exec.

Granted, that's for files, where if you want two independent opens of
the same file it's mostly not difficult to get them. For sockets that
isn't a thing. 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.

(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.)


(also, "mirabile visu")
-- 
David A. Holland
dholland%netbsd.org@localhost