13 Oct
2018
13 Oct
'18
9:11 p.m.
Hi Harald,
Thanks for clarifying, and sorry about myself missing some parts of the
whole thread.
But if there is nothing yet implemented, I could do a proof of concept.
I wrote a system for a company in the past for a DTV ISDB-T encoder
which was multi-processes which used shared memory and locks (residing
inside the shared segment) for access to it. We can talk in person next
week.
Rafael
On 10/12/2018 10:28 AM, Harald Welte wrote:
Hi Rafael,
On Fri, Oct 12, 2018 at 10:00:14AM -0300, Rafael Diniz wrote:
Hi all,
yes, that is what I'm saying and why we have been brainstorming about
this approach at all. That's what I've been talking about in the first
paragraph you quoted, and what we've been pondering to do.
The second paragraph is about embedded or external databases which we
don't want to use, and whihc are not useful within the current osmocom
architecture.
I've done some research on the web at that
time (maybe 2 years ago) but
unfortunately couldn't find any library/tool/infrastructure for having
persistent data in SysV SHM, and also no other FOSS programs that did
so. Maybe I didn't look closely enough? To me, it seems like the most
obvious solution to persist state across crashes/restarts of C programs
on unix-type systems.
We explicitly don't want to use some kind of database system, as the VLR
data needs to be accessed all over the code
directly/synchronously/non-blockingly. We cannot wait for it to be
retrieved from somewhere. That's what is done with HLR data.
May be I'm missing something, but SysV SHM provides system calls you
certainly can create a shared memory segment that is persistent.