shallow thoughts on SHM
jamesb.fe80 at gmail.com
Sun Oct 27 20:00:00 UTC 2019
On Sat, Oct 26, 2019, at 8:24 PM Hal Murray <hmurray at megapathdsl.net> 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
> 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
> 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.
> I want to send something like this over a network connection, I build it
> 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 drown.org> wrote:
> You might consider the unix socket refclock format supported by
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...
More information about the devel