From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 19 May 2014 08:50:20 -0400
To: 9fans@9fans.net
Message-ID: <9c783f88daab742653c28a777599956b@brasstown.quanstro.net>
In-Reply-To: <2faa44c1fd358d72fac821c3cb683392@proxima.alt.za>
References: <2faa44c1fd358d72fac821c3cb683392@proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] syscall 53
Topicbox-Message-UUID: e8451f22-ead8-11e9-9d60-3106f5b1d025

> Which raises another question: are 9atom and 9front in synch with the
> BL distribution (itself in question) regarding syscall 53?

9atom is not.  i didn't know that it was added, nor do i=20
know why nsec was added as a syscall.

i indirectly heard "go needs it", but that is not really a reason
i can understand technically.  why must it be a system call?

getting ahead of myself, if the problem is shared memory vs
shared fds, then the solution is easy: fix nsec in the c library.
don't save a copy of the fd.  that leads to trouble.  (the new
call takes ~6=C2=B5s on my e3 v2)

if the problem is getting very low-latency timing, or relative
timing, then the solution is still easy: use the timestamp counter.
no version of nsec works for relative timing due to timesync
adjustments!

i'm sure there are other possibilities, i don't think i see them without
an explination.  so if anyone has anything else, that would be
interesting.

- erik

---
; cat /sys/src/libc/9sys/nsec.c
#include <u.h>
#include <libc.h>

vlong
nsec(void)
{
	uchar b[8];
	int fd;

	fd =3D open("/dev/bintime", OREAD);
	if(fd !=3D -1)
	if(pread(fd, b, sizeof b, 0) =3D=3D sizeof b){
		close(fd);
		return getbe(b, sizeof b);
	}
	close(fd);
	return 0;
}