Proposal - drop the GPSD JSON driver

[Hal Murray]

esr at 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.


> 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 
sends deltas.


> 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
CONFORMING TO
       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.