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