This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Rafael Diniz rafael at rhizomatica.orgHi 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, >> >>> 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. > > 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. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20181013/31fbbc0d/attachment.bin>