Andrei Pelinescu-Onciul wrote:
On Feb 16, 2010 at 12:47, marius zbihlei marius.zbihlei@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