On 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 <lafo...@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)