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.
