Yo Eric!
On Thu, 20 Oct 2016 00:02:38 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > So, a shared memory driver for ntpd?
>
> It already has one.
Not a POSIX sharde memory one. And the exsting one has serious
problems.
> I think the one it has would be as good as we
> need if not f
g...@rellim.com said:
> Not a POSIX sharde memory one.
What do you mean by POSIX in this context? How would I recognize one if I
was looking at it?
> Say what? The existing protocol has serious problems.
What sort of problems are there with the current one?
--
These are my opinions.
Hal Murray :
>
> e...@thyrsus.com said:
> >> So, we all vote for JSON in POSIX SHM?
> > I don't. I think this is one of the very rare cases where passing a C stru=
> > ct as a binary blob makes sense. We want to minimize offset and jitter and
> > there's no cross-architecture problem.
>
> Don'
Gary E. Miller :
> Oh, please not! That is one of the big problems in the existing driver.
> Way too compiler, CPU and OS dependent. Plus not extensible. The
> exsting C struct has been nothing but problems. Maybe you don't buy into
> JSON, but the C struct is a non-starter.
Way too compiler,
Hal Murray :
>
> e...@thyrsus.com said:
> > Same thing with JSON. The client can't predict when JSON will come up the
> > wire.
>
> The client is normally waiting in the big select. It will get woken up as
> soon as data is available.
Oh, now I see what you mean. You're right.
Hm. That's
Yo Hal!
On Thu, 20 Oct 2016 03:38:00 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > Not a POSIX sharde memory one.
>
> What do you mean by POSIX in this context? How would I recognize one
> if I was looking at it?
We are talking about the shared memory functions that POSIX defines.
r
Yo Eric!
On Thu, 20 Oct 2016 07:34:18 -0400
"Eric S. Raymond" wrote:
> Hal Murray :
> >
> > e...@thyrsus.com said:
> > > Same thing with JSON. The client can't predict when JSON will
> > > come up the wire.
> >
> > The client is normally waiting in the big select. It will get
> > woken
Yo Eric!
On Thu, 20 Oct 2016 07:11:20 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Oh, please not! That is one of the big problems in the existing
> > driver. Way too compiler, CPU and OS dependent. Plus not
> > extensible. The exsting C struct has been nothing but problems.
> > Mayb
Gary E. Miller :
> > What sort of problems are there with the current one?
>
> Do we really need to go over this yet again? These have been covered
> for years.
>
> First, the structure needs to be polled, sometimes leading to long
> delayed and even missed samples.
This will be the case with a
e...@thyrsus.com said:
> Hm. That's an argument for something with a wait or ready signal. Not an
> argument for JSON in SHM. Might mean we need an auxiliary semaphore to do
> sem_wait on; not a problem.
I was never interested in JSON in SHM.
sem_wait doesn't work with select. You would hav
Hal Murray :
> sem_wait doesn't work with select. You would have to do something like setup
> another thread and have it send a byte down a pipe. (The DNS lookup path
> does that. It may be on end-of-thread rather than data-ready.)
Yes, I've been thinking about mechanisms for this. They're a
Eric S. Raymond :
> Hal Murray :
> > sem_wait doesn't work with select. You would have to do something like
> > setup
> > another thread and have it send a byte down a pipe. (The DNS lookup path
> > does that. It may be on end-of-thread rather than data-ready.)
>
> Yes, I've been thinking ab
e...@thyrsus.com said:
>> The SHM interface is deltas. gpsd figures out the offset and sends that
>> over to ntpd. How gpsd figures out that offset has nothing to do with SHM
>> or JSON or anything else involved with getting the data to ntpd. The
offset
>> won't change much in a short time so
e...@thyrsus.com said:
>> Yes, I've been thinking about mechanisms for this. They're all rather
>> irrelevant.
> Argh. I meant "inelegant".
I assume that using a pipe or socket rather than SHM would fix that.
--
These are my opinions. I hate spam.
_
Yo Eric!
On Thu, 20 Oct 2016 16:11:41 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > > What sort of problems are there with the current one?
> >
> > Do we really need to go over this yet again? These have been
> > covered for years.
> >
> > First, the structure needs to be polled, so
Yo Eric!
On Thu, 20 Oct 2016 16:52:06 -0400
"Eric S. Raymond" wrote:
> > The SHM interface is deltas. gpsd figures out the offset and sends
> > that over to ntpd. How gpsd figures out that offset has nothing to
> > do with SHM or JSON or anything else involved with getting the data
> > to ntpd
Yo Hal!
On Thu, 20 Oct 2016 14:19:05 -0700
Hal Murray wrote:
> e...@thyrsus.com said:
> >> The SHM interface is deltas. gpsd figures out the offset and
> >> sends that over to ntpd. How gpsd figures out that offset has
> >> nothing to do with SHM or JSON or anything else involved with
> >> get
Hal Murray :
>
> e...@thyrsus.com said:
> >> Yes, I've been thinking about mechanisms for this. They're all rather
> >> irrelevant.
> > Argh. I meant "inelegant".
>
> I assume that using a pipe or socket rather than SHM would fix that.
Probably, but then we run unto buffering jitter again.
Y
18 matches
Mail list logo
