Re: [9fans] a pair nec bugs

[Charles Forsyth <forsyth@terzarima.net>]

the most straightforward fix for nsec
is to change it back to do the obvious thing: open the file,
read in the time data, close the file and return the value.

we might like to add the cache back in, since a grep of /sys/src/cmd
suggests that it might be useful to do that.
most programs were fine with a statically-allocated
file descriptor, closed on exec, and using pread not read
to avoid the shared offset. complications arose with
forks when file descriptors were rearranged, sometimes with an extra twist when
the forks share data apart from the stack. programs do those things
by explicit calls.

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.

file descriptors are just one form of shared state.
is it possible to devise a call or pair of calls
to manage library state such as shared file descriptors and static values
for a process or group of related processes?  it seems tricky,
and probably overly elaborate, since a memo about
existence of some state to invalidate is itself state.

perhaps it is better for each relevant library module to expose the
existence of its cached state through a function call to invalidate it
(or otherwise manage it explicitly) when needed.

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