Proposal - drop the GPSD JSON driver
hmurray at megapathdsl.net
Thu Oct 20 05:28:35 UTC 2016
esr at thyrsus.com said:
> Same thing with JSON. The client can't predict when JSON will come up the
The client is normally waiting in the big select. It will get woken up as
soon as data is available.
> Originally GPSD JSON wasn't really supposed to be an externally exposed
> protocol at all. GPSD ships both C and Python libraries to avoid this; I
> wanted control of both ends so the protocol should change if it needed to.
Ahh. OK. That's another interesting can of worms.
> JSON reflects one set of priorties: extensibility of the protocol and
> eyeball-friendless are more important than minimizing latency or jitter in
> most cases.
But it doesn't add significant latency or jitter. Latency isn't critical in
the below 1 ms range. There is much more latency in SHM. Where do you think
the jitter is coming from? All the time critical work is done in gpsd. It
> but the same amount of time spent on (say) a POSIX SHM driver would have
> paid off better
What does "POSIX SHM" mean?
I think there are two parts to SHM. One is setting up a chunk of shared
memory. The other is passing data from one process to another. That part
needs memory barriers or semaphores or something like that.
My man page for shmget says:
shmget - allocates a System V shared memory segment
POSIX.1-2001, POSIX.1-2008, SVr4.
Is that POSIX?
The problem with semaphores is that I don't see a clean way to initialize
them and/or recover from crashes.
The advantage of a pipe or socket is that they fit in to the select we have.
I don't believe the cycles associated with either will be significant, but I
don't have numbers to back that up.
Maybe we should start a side project to write some clean sample code an/or
collect some timings.
These are my opinions. I hate spam.
More information about the devel