16 Feb
2010
16 Feb
'10
7:41 a.m.
Andrei Pelinescu-Onciul wrote:
On Feb 16, 2010 at 12:47, marius zbihlei
<marius.zbihlei(a)1and1.ro> wrote:
You need this callback to be called the moment the value is set (1),
in each process, before the updated config is used (2) or once, before
the updated config is use the 1st time (by the first process that needs
to access it) (3)?
If (2) is ok, then use the on_set_child_cb (next field in the cfg_def).
If (3) is ok, then set CFG_CB_ONLY_ONCE among the flag and use the
on_set_child_cb, like for (2).
Hello,
What I really wanted was 1, when the cfg value was change the statistics
are also updated. But I guess this can't be easy done (requires changes
to cfg framework). As I only need the value changed once, and
statistics aren't per process, I guess 3 is the better option.
I don't completely understand the whole "before the updated config is
used". This means a cfg_update() is required or I don't have to do
anything the update being done transparently from the user(myself) point
of view. If I issue a sercmd cfg.set_now_int this will mean that the
child_cb will be called at the time of the update(the value being
changed now ?!) ?!
If I need to call cfg_update(), then I can call it from the "save"
function export of the registrar module(and all other function exports
called from ser cfg script). If this will make the child_cb to get
called, then I can update the statistics from there. The window between
the cfg value is changed and the changed is reflected to statistics is
limited by the next call to a registrar function export when a sip
messages is processed.
Another thing. Do I need to use cfg_update() periodically to ensure that
values from cfg framework are consistent in the modules?! After looking
at some examples in modules/tm I presumed that a call to cfg_get(...) is
enough to get the updated value (Note that I don't have any child
processes in the module - if there were children I would call
cfg_update() from the infinite loop of the child).
So far I guess nobody had a fixup that didn't
change the value :-)
I can think of two cases when the value is not changed/transformed
1. A change in cfg framework generates some internal module changes
(like a reread of a database, update of statistics). I think this can be
achieved via child_cb.
2. The fixup tests to see if the value is correct (like expecting a
string from a already known lists of strings). No changes are possible
and if the user gave smth wrong, sercmd will inform it at once . This
can't be achieved via child_cb.
Thanks for the help
Marius
Any ideas
welcome.
In the long run we have to fix somehow the var. w/
fixup unreadable
problem. Maybe we should add a cfg_on_display callback (but then we
would have to update a lot of cfg_defs).
Andrei