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/.
Pau Espin Pedrol pespin at sysmocom.deHi, On 3/20/19 5:43 PM, Harald Welte wrote: > Hi Pau, > > On Wed, Mar 20, 2019 at 01:04:04PM +0100, Pau Espin Pedrol wrote: >>> 1) initialization of the various sub-systems is too complex, there are too >>> many functions an application has to call. I would like to move more >>> to a global "application initialization", where an application registers >>> some large struct [of structs, ...] at start-up and tells the library >>> the log configuration, the copyright statement, the VTY IP/port, the config >>> file name, ... (some of those can of course be NULL and hence not used) > > One addition here is also vty initialization. It sucks that everyone has to manually > install the VTY commands for talloc, etc. - that should just happen automagically > in some way. Fine with that. Anyway that's done at initialization, before multiple threads/workers are started, so no issue there with multithread. > Another topic that I forgot to list is signal handling. I would think it makes > sense to move the SIGUSR1/SIGUSR2 handling into libosmocore now, particularly > as we have the root talloc context[s] in libosmocore with my related patches. > It just sucks to have to have a SIGUSR1->talloc_dump code snippet in each and > every of our programs. Please don't. Let's allow apps decide how they handle user-defined signals and not try doing everything in a generic library. Some app using libosmocore may want to do something else under SIGUSR1/SIGUSR2. I really prefer having this kind of stuff being done in the app and not in the library. If still you want to do it, at least document clearly what libosmocore does and how to let apps overwrite the signals (so it becomes a "public" feature and not some hidden-implementation requirement). > >> Turn state into thread-local storage makes sense. No need for different sets >> per thread imho. Loosely related: It may be good to refactor code to allow >> for other polling systems (like epoll()), which may be more efficient if we >> have a long set of file descriptors but only a few are triggered every loop >> step. > > That's a good point, indeed. It's been on the wishlist for a long time, but nobody > appeared to have been reporting any performance issues as of yet. Ideally we > wouldn't have to change our 'struct osmo_fd' at all but simply call a > different "osmo_select_main()" function which would then call epoll instead of select. Maybe is as easy as having a compile flag which builds osmo_select_main against epoll() if existent, and use select() as fallback. > >> Regarding some other thread you wrote recently, I don't see much issue in >> having VTY library code not supporting multithread,since you can always >> force polling it from same thread and then if your process is multithread >> you take care of message passing between threads yourself in the VTY >> app-specific code. > > I agree we shouldn't tackle this problem now. However, we have many sub-systems > that e.g. add a "show ..." VTY command. That command iterates over some dynamically > created structures, like e.g. subscriber connections. So if we were in a multi-threaded > environment where external events/messages were processed in other threads than > the main thread that runs the VTY, then we can no longer simply iterate over any > of those lists, but we'd have to have mutexes/rwlocks/RCU/... to synchronize. > > That's out of scope for now, as we don't have any big plans for multi-threading > in a big way just yet. We can look at it if we ever get to that point. Sure, I'm not expecting multi-threaded for current apps so far (perhaps osmo-mgw in the future?). IF we add multi-thread to those we'll need this kind of changes. I was howerver thinking about new apps, which will already have this kind of tools/architecture in place since time 0. >> For logging code we may want to add some callback which provides the >> application with some way to lock/unlock a mutex or something similar. If cb >> is NULL, then there's no performance penalty during logging. > > Not sure I understand you here. The problem starts if we use multiple printf() > calls to write a signle line, especially with LOGPC/DEBUGPC > > This introduces problems if multiple threads writing to the same log output > then garble / intersperse each others output at points that are not the end of > a lot line. > > Especially with the new _buf() and even the _c() variants of our various stringify > functions it should be possible to convert all callers of log functions to hand > in a full line in one call and remove the LOGPC/DEBUGPC for continuation. > > Once we reach that point, at least log stdout/stderr/file will be ok, as glibc > guarantees that a single write/printf is "atomic". Not sure about our VTY > log backend, though. > Indeed, I was thinking about LOGPC/DEBUGPC and other backends like VTY here. Regards, Pau -- - Pau Espin Pedrol <pespin at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte