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/.
Harald Welte laforge at gnumonks.orgHi Michael,
On Fri, Oct 12, 2018 at 09:08:20AM +0200, Michael Andersen wrote:
> >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.
>
> Lightning Memory-Mapped Database
> (https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database) is designed
> for exactly these requirements.
Thanks for your suggestion. After reading through the documentation I could
find, I am not convinced it actually is applicable to our use case / requirements.
Osmocom programs, like OsmoMSC are non-blocking single-threaded event-loop driven
designs. We cannot at any point run into a situation where there is a blocking
read or blocking write to disk/file. Doing so would kill performance for all
other concurrent transactions in progress.
> It gives non-blocking access to the data - directly in-memory. Yet it also
> persists the data to disk in the background. So in case the software is
> restarted, it can pick off exactly where it left its dataset.
AFAICT from a very quick look at the source code, the writing-to-disk is not
performed "in the background" but it is rather performed as blocking write()
calls in the process/context at which the data is acessed?
So to me, LMDB more looks like BerkeleyDB or SQLite but with a layer of zero-copy
memory cache/access at runtime on top of it?
We don't want blocking/IO. We don't want disk I/O at all. We don't want
persistency across system reboots or the like, but only persistency across
restarts/respawns of the specific process. Hence my argument in favor of
a SysV SHM segment, which fullfills the criteria. If anyone has any pointers
for examples of FOSS programs or libraries where that has been done before, it
would be much appreciated.
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)