> 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. > 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".) Looking at the include files, it looks to me as though descriptors are indices into an array of structs (struct fdfile) in -current or 5.2, or an index into two parallel arrays of pointers and flags in 1.4T. Those then point to the structs file (the per-open state). It's true the flags fields are chars (two bits used in 1.4T, two separate chars storing one bit each in 5.2 or -current). But it's a far cry from being as bad as you outline. There are multiple bits free, and, even if they run out, growing them from chars is a low (memory) cost on 1.4T and probably zero on 5.2 and -current on most ports. > For a couple bits you can mask them off from the pointer (though even > that's abusive); If that were what were being done, I would agree it'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. That is quite possibly why 1.4T uses parallel arrays rather than an array of structs. In 5.2 and -current, there is enough additional state that someone (rightly, IMO) decided it wasn't worth the code complexity of keeping parallel arrays. (See struct fdfile in sys/filedesc.h for the additional state I'm talking about.) > (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? > (also, "mirabile visu") What did I write? *checks* Oops. Thanks. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B