shallow thoughts on SHM

James Browning jamesb.fe80 at
Sun Oct 27 20:00:00 UTC 2019

On Sat, Oct 26, 2019, at 8:24 PM Hal Murray <hmurray at> wrote:

> > I do not have access to a copy of POSIX and the SuSv2 seems to have SHM
> > support.
> You can probably get what you need from man pages.  Try man shm_overview

There are links in the documentation that I should have read before
removing all doubt.

>  I'd be happy to switch to POSIX SHM, but the current code works so I
> don't see

any point in doing that until we decide what else to do in this area.
> Linux, NetBSD, and FreeBSD all support POSIX SHM.  How many other OSes to
> we
> currently support?  Can somebody see if they have shm_open?

POSIX SHM support in a quick bit of web searching seems largely a
Linux and BSD derivative thing.

> You are worrying about the weeds when we haven't even found the forest yet.

Noted, it is one of my defects.

> Changing it to use say a UNIX socket would allow for simpler packet
> > design.
> That approach is worth investigating, but it adds a layer of complexity if
> you
> want to support more than a single reader.

In that instance, I am not handling multiple readers. To handle
multiple readers it would have to be sent to a non-unicast address
(or something). Then securing things becomes an issue. Tacking on an
eight-byte trailer probably would not cut it.

> Why do you think it is simpler to design a packet than a memory layout.
> When
> I want to send something like this over a network connection, I build it
> in
> memory, then call send() or one of its friends.

 Because I would not need to worry about locking, semaphores or mutexes as
is someone-else's-problem. I could build a packet, throw it and no have to
whether one process is faster, slower or roadkill.

On Sat, Oct 26, 2019, at 2:14 PM Dan Drown <dan-ntp at> wrote:

> You might consider the unix socket refclock format supported by
> gpsd/chrony:

I have looked at it and it has issues. The presumably 'secret' magic
value is not. The use of a double however seems to allow for the
accurate representation of time offsets greater than the panic
threshold, while allowing (what I would consider reasonable) accuracy
up to a few NTP eras of offset. The use of unsized (u)ints and timeval
means that there is the possibility of functionally different structs
being used on the sending and receiving ends.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list