SHM

[Mark Atwood]

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 <gem at rellim.com> wrote:

> Yo Hal!
>
> On Fri, 06 May 2016 13:56:43 -0700
> Hal Murray <hmurray at 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
>         gem at rellim.com  Tel:+1 541 382 8588
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160507/2f024168/attachment.html>