absolutke not to json over shm. once you have done that, with the needed mutexes and ring pointers, you have just literally reimplemented unix domain socket in user space, less safely
On Fri, May 6, 2016, 2:10 PM Gary E. Miller <g...@rellim.com> wrote: > Yo Hal! > > On Fri, 06 May 2016 13:56:43 -0700 > Hal Murray <hmur...@megapathdsl.net> wrote: > > > > Are we presently using the old one? Where is documentation for the > > > new one? > > > > Do the old and new SHM schemes share the same name space? If gpsd > > uses old, can a ntpd using new talk to it? > > No, fundamentally incompatible at the ABI level. So it would have > to be a totally new refclock. Unless we find another QNX type issue > that needs fixing, a half step not worth making. Better to work on > refclockd and fixing current refclocks. > > But, just to totally muddy the water... > > Some people worry about the latency issues in the JSON. I doubt they > exist, > but if they did, then the solution would be to run JSON through shm_open() > style shared memory. We get file system style security and shared memory > style speed! > > So just keep shm_open() in the back of your mind, someday it might be a > solution to a hard problem. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > _______________________________________________ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
