[TangerineSDR] List of Software Modules to be Designed

[Rob Wiesler]

Bill, sorry for yet another duplicate reply.  I've been putting it
off, but it's probably time for me to switch from Gmail's web
interface to mutt, as I have done for work.

On Thu, Oct 24, 2019 at 10:48 PM Rob Wiesler <rpw10 at case.edu> wrote:
> On Thu, Oct 24, 2019 at 9:24 PM Engelke, Bill <bill.engelke at ua.edu> wrote:
> > Hello Rob - I was not including SYSV as the IPC.
>
> That's good, but many of the criticisms I have of using shared memory
> IPC still apply.
>
> > I have seen articles discussing the POSIX approach using a backing file - see the shared memory discussion about halfway through this article: https://opensource.com/article/19/4/interprocess-communication-linux-storage
>
> I haven't read the link, but I know the technique (you map a new
> memory block using mmap(2), backed by a file, which may or may not
> already exist or be in similar use by other processes).  It's almost
> never what you want, as you have to deal with protocol semantics and
> locking that are best done for you via another method.  Instead, a
> more structured IPC method is usually what you want.  For instance, if
> you use a Unix socket, you get:
> - In-order arrival of messages, with no locking required by the application
> - Single-threaded asynchronous IO via select(2), poll(2), epoll(2),
> et. al., because the socket is backed by a file descriptor (this
> doesn't work for shared memory IPC, or may Ward Cunningham strike me
> down)
> - Immediate interoperability with programs that use stdin/stdout for IO
> - Bindings in every programming language, with no arcana
> - A standard interface that requires little to no code to share
> between different software agents using it
> - Knowledge of the local system user (and group) on the other side of
> the pipe, courtesy of the kernel (useful for security reasons) (no
> password/authentication needed)
>
> > Is this the filesystem approach you mentioned? It appears to work with a sort of virtual file.
>
> No, this is the file hand-off system using inotify that I mentioned in
> a previous thread (or two).  The idea is that agent A saves data to a
> file, and agent B uses inotify to wake up when A finishes writing (and
> closes) each file in a particular directory.  This needn't touch a
> disk - you can mount a tmpfs somewhere so that all of this happens in
> memory.  This has the advantage of being easily adaptable to
> persistent storage of queued data files, and it's also very easy to
> engineer (you can write software agent A completely separately from
> software agent B).  However, it's usually better just to use a pipe or
> socket if you don't care about that.
>
> If you want to send binary structures in memory between processes,
> sockets are still probably the best way to do it - you can always send
> a binary structure through a pipe or socket and cast it back to the
> proper C type on the other side.
>
> > There is a follow on article by the same author which discusses using Unix sockets here:
> > https://opensource.com/article/19/4/interprocess-communication-linux-networking
> >
> > Are there dramatic differences between these that would make a big difference in an application like we plan for the SBC?
>
> Yeah, as I've mentioned.  There's only one or two real advantages to
> using a shared-memory IPC method, which are that you can devise very
> exotic multi-agent communication systems without being tied to the
> structure of an existing IPC method, and that in some cases you can
> design a zero-copy data pipeline with multiple processes.  We want
> neither of these things.