Hi,
On 3/20/19 11:13 AM, Harald Welte wrote:
While working on the talloc context patches, I was wondering if we should
spend a bit of time to further improve libosmocore and collect something
like a wishlist.
I would currently identify the following areas:
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)
2) have some kind of extensible command line options/arguments parser
It would be useful to have common/library parts register some common
command line arguments (like config file, logging, daemonization, ..)
while the actual appliacation extending that with only its
application-specific
options. I don't think this is possible with how getopt() works, so
it would require some new/different infrastructure how applications would
register their arguments
1 and 2 not really worth for me. I'm not against it, but I'm happy
enough with current state.
3) move global select() state into some kind of structure. This would mean
that there could be multiple lists of file descriptors rather than the
one implicit global one. Alternatively, turn the state into thread-local
storage, so each thread would have its own set of registered file
descriptors,
which probably makes most sense. Not sure if one would have diffeent 'sets'
of registered file descriptors in a single thread. The same would apply
for timers: Have a list of timers for each thread; timeouts would then
also always execute on the same thread. This would put talloc context,
select
and timers all in the same concept: Have one set of each on each thread,
used automatically.
Turn sate 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.
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.
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.
Regards,
Pau
--
- Pau Espin Pedrol <[email protected]> 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
