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
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);
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
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.---BeginMessage---
On Sat May 21 18:12:35 EDT
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
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
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
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
Or one file containing the two numbers. But perhaps they change...
On 20 May 2011 11:45, ron minnich 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
On Fri, May 20, 2011 at 3:52 AM, roger peppe rogpe...@gmail.com 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
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.
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 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
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
i've been having trouble with nsec. i've been dealing with an application
that has ~128 processes. it does not use the thread library, but these
processes all share memory. unfortunately, this results in wild thrashing
of nsec(2) because there are more shared-memory processes than slots
in the
18 matches
Mail list logo
