Proposal - drop the GPSD JSON driver
hmurray at megapathdsl.net
Wed Oct 19 10:51:29 UTC 2016
I think you should leave it until we get our act together, and I think you
should put that on the back burner until 1.0 is out.
> For communication with GPSD, the SHM driver seems superior; it certainly has
> lower processing overhead and therefore introduces less noise into the
> delivery chain.
It has a different type of noise. There is no "ready" signal on SHM so the
driver polls and the timing on that is just the luck of when ntpd was started.
I think the SHM driver is pretty ugly. It got a lot less ugly when you added
the memory barriers a year or two ago. I think we should rewrite it to use
the 2 counters trick so the readers are read-only. But let's save that
discussion for another time.
I'm missing the big picture. The JSON driver was written because I (and
probably others) thought you thought that JSON was the right way to talk to
gpsd. Was that wrong and/or did anything change?
Can POSIX SHM talk to non-POSIX SHM? I assume the concepts are the same (map
a chunk of memory where I can see it). Are there different name spaces?
Would pipes work better? Or a network connection passing the same (binary)
info as is in the SHM segment?
These are my opinions. I hate spam.
More information about the devel