Re: [9fans] a pair nec bugs

[erik quanstrom <quanstro@quanstro.net>]

> we've had several attempts at trying to guess in the library's
> guts when the cached value(s) have gone wrong, but they haven't worked
> because there are too many cases and the library function can't detect them precisely
> if at all. also, using the current process as the cache key probably isn't right:
> often it's fine for the file descriptor to be shared by a group;
> on the other hand, if each process has its own file descriptor,
> there's no way to tell when the descriptors have been rearranged.
> nor can the program currently tell the library what it has done.

while it is a bit clunky, i think nsec() can detect whenever it could
have the wrong fd and it can limit itself to 1 open per pid, which
would seem to be the case where it could make a big difference.
(that's the code i posted.)  it seem's oddly like ken's file server's
read ahead algorithm.  start read ahead when the second block
in a row is read.

it may open too many fds, but i believe it doesn't improperly
use fds, thrash when a table gets full, nor go into an infinite
loop under adverse conditions.

> file descriptors are just one form of shared state.

so are note groups.  the difference is we can get the note group
id from user space.  we can't do this with fd groups.  (there's
really no such concept.)

> syslog, times and truerand(!) also would benefit.
> of all of them so far, only times(2) really is per-process.

i suppose there are a couple of more precise ways of
dealing with this shared state.

1.  we already have an open flag OCEXEC.  wouldn't these
problems also be solved by a flag that closed the fd in
the child when the file descriptor table was copied?

2.  wrapping rfork so that rfork detects RFFDG, and
invalidates the child's cached file descriptors.

- erik