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.orgOn Thu, Aug 12, 2010 at 04:23:39PM +0200, Andreas.Eversberg wrote:
> hi,
>
> it would make sense to run database lookup in a seperate thread (with
> lower priority). but in this case the database request function of
> openbsc will not have a result at the time they return. it would take
> some changes of the processes which do database lookups. i think it will
> be some work, but it can be done.
sure, this asynchronous database lookup is on the TODO list for a long time,
but hasn't been implemented yet. The reason for this in turn is that I
wanted to make the asynchronous lookup then use the MAP-over-TCAP protocol
to actually interact with the HLR. And in order to do that, the libosmo-tcap
etc. has to be verified and stable - which I'm more or less into now.
The idea also was to do this new asynchronous lookup + TCAP/MAP stuff, plus the
corresponding HLR first from the SGSN, as OsmoSGSN is more experimental than
OpenBSC. Once it works in OsmoSGSN, I intended to port it to OpenBSC.
Now, making OpenBSC deal with an asynchronous lookup and interfacing it with
MAP and a more-or-less real HLR are two separate issues, so I don't mind
that. However, spawning extra threads in OpenBSC is not something I'm
particularly happy about. It is written as a single-threaded program,
and that's intentional.
If the counters cause problems, we can either simply put them into a completely
different database, or forget about the counters (disable them by default).
If that solves the problem, I think it is not worth doing some kind of hacks
(like a DB thread within OpenBCS) and simply go for the "real" solution
with external HLR process and communication over MAP/TCAP/SCCP
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)