> > I put the OSX launchd ritual on the wiki a couple of years ago.
>
> and here it is:
> http://www.plan9.bell-labs.com/wiki/plan9/9pfs.plist/index.html
Ugh, that has been throughly eaten by the wiki formatting,
I think this is the bit I added:
http://www.plan9.bell-labs.com/wiki/plan9/Int
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 w
> 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
Since I have noticed that all the lists I'm subscribed to are almost
silent, and since north america generates the majority of the traffic
on these lists, I suspect there is something to do with "yours" doom
days.
Could US citizens provide a calendar about the next "final days" so that
one can rem
> syslog, times and truerand(!) also would benefit.
> of all of them so far, only times(2) really is per-process.
and time(2).
- erik
>and time(2).
i didn't include that because it calls nsec
On Sat May 21 18:12:35 EDT 2011, fors...@terzarima.net wrote:
> >and time(2).
>
> i didn't include that because it calls nsec
time calls an internal function, oldtime(),
that adds another private file descriptor.
i suppose that could be killed off by now.
- erik
