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 dholl...@netbsd.org