Proposal - drop the GPSD JSON driver

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 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 all rather
irrelevant.

> > There's an easy way to take GPSD's heavy computation work out of the budget
> > that we haven't used yet.  You take a nanosecond-precision timestamp on the
> > first read of data from the device. You take a second timestamp just before
> > you ship.  You bump the fix time by the difference between the second and
> > first timestamps. 
> 
> I can't figure out what you are trying to do.
> 
> 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 modest latency doesn't matter.

Your last sentence is one of the assumptions we're now questioning.  I didn't
question it before either, which is why the above hack is not implemented.

As you say, we need to try several methods and measure.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>