Charles Forsyth wrote:
what about applications that need to get the nsec frequently?
*in those applications*, i write
Hi, all
Last month I had problems in a appl made up by 12 threads using a shared
file table.
Six of them continuosly get the time every 20..100 ms.
The last version of th
> unfortunately, that one still fails:
i was willing to accept the fact that closing random file descriptors
could result in lossage at this point to solve the infinite loop problem.
(and any library function that opens a fd is potentially racing with
any other thread closing random fds.)
it's wo
unfortunately, that one still fails:
h% 8c -w nsec.c
h% 8l nsec.8
h% 8.out
1307094033073099818
1307094033079570483
0
my approach is a little different.
in the library:
vlong
nsec(void)
{
uchar b[8];
vlong t;
int fd, n;
fd = open("/dev/bintime", OREAD);
i
here's what i settled on for now. i believe it to
be correct in all cases, but if you are sharing file
descriptors among many processes, you may have
/dev/bintime open many more times that necessary.
i put off solving other instances of fd-group private
until later, since the solution in hand is
>time calls an internal function, oldtime(),
>that adds another private file descriptor.
that's only a fall-back if the call
to nsec doesn't work because you're running on a kernel
that's years and years out of date; so it isn't really
relevant here.--- Begin Message ---
On Sat May 21 18:12:35 EDT
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
>and time(2).
i didn't include that because it calls nsec
> syslog, times and truerand(!) also would benefit.
> of all of them so far, only times(2) really is per-process.
and time(2).
- erik
> 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
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
here's an improved version. the previous version had a problem when
shared memory but not shared fd in this situation
p0:
nsec() -> fd 3
...
p1:
open() -> fd 3
nsec() -> fail
one potential modification is to ditch
On Fri May 20 15:04:48 EDT 2011, rminn...@gmail.com wrote:
> I did not read your post as carefully as I should, but I still have
> concerns when people use stuff like nsec() in the quest of accuracy.
> Sorry, I was sort of reacting to another thread in the Go list where
> somebody is using gettimeo
I did not read your post as carefully as I should, but I still have
concerns when people use stuff like nsec() in the quest of accuracy.
Sorry, I was sort of reacting to another thread in the Go list where
somebody is using gettimeofday() and seems to think the nsec field has
meaning :-)
We don't
On Fri May 20 06:44:51 EDT 2011, rminn...@gmail.com wrote:
> I think the growing complexity of nsec() shows that the file model
> doesn't work in all cases ... the thing starts to look a bit overly
> complex to me. The fact that it fails due to the size of a static fd
> array is also a warning flag
On Fri, May 20, 2011 at 3:52 AM, roger peppe wrote:
> Or one file containing the two numbers. But perhaps they change...
sadly, for the tsc, they do.
But there are supposed to be counters in there that don't suck.
ron
Or one file containing the two numbers. But perhaps they change...
On 20 May 2011 11:45, "ron minnich" wrote:
> I think the growing complexity of nsec() shows that the file model
> doesn't work in all cases ... the thing starts to look a bit overly
> complex to me. The fact that it fails due to th
I think the growing complexity of nsec() shows that the file model
doesn't work in all cases ... the thing starts to look a bit overly
complex to me. The fact that it fails due to the size of a static fd
array is also a warning flag.
I think a better interface would be one in which you read two va
17 matches
Mail list logo
