Re: Per-descriptor state

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B