On Feb 16, 2010 at 14:41, marius zbihlei <marius.zbihlei(a)1and1.ro> wrote: You need to worry about cfg_update() only if you fork new processes and want to use the cfg framework from them. In general the cfg is updated for each "normal" process when a new message is read. on_set_child_cb will be called by each process when its config needs updating (the global config pointer differs from the local one), so the answer to your question is "yes" (if no message comes, then no cfg_update() will happen for some time, so the callback might be called at a later time, at most TIMER_HANDLER_INTERVAL later). Note also that if you want to use on_change_cb instead of on_set_child_cb, there is another issue. The cfg can be updated immediately, or on commit (e.g cfg.set_delayed_int and cfg.commit). However the cfg variable fixup (on_change_cb) is called immediately in both cases (because it's supposed to "fix" the value and not do some other stuff). So if you do something from on_change_cb, then it will probably break the cfg.set_delayed_int & cfg.commit case (the change will happen immediately and not at cfg.commit time). I had this bug in older versions for the sctp options. I used to do setsockopt()s from the fixup instead of the per child callback. Now they are done via the per child callback with the CFG_CB_ONLY_ONCE flag set (see sctp_option.c "autoclose" for an example) cfg_update() is called each time a message is received and periodically by the timer. If you use (3) then you will have at most 1/16 s delay in the worst case. If this is not good enough for you, then I think we could add a call to cfg_update() at the end of cfg_commit() and cfg_set_now() (this would cause an update immediately after a commit or set_now and so it would trigger the immediate execution of the per child callbacks). Yes, you do have to call cfg_update() periodically if you want to make sure you have the latest config version for the non-atomic declared config vars. However cfg_update() is already called in all the processes (e.g.: each time a new message is received in the receiver processes and each timer tick in the timer process). In general it means that some of the new config values would be visible in a process only for future messages and not for the one that is currently being processed. This is a feature (it's a guarantee that any non-atomic-marked config var. would not suddenly change while you're processing a message) and updating more often will break several things (depending on the process, e.g. there are some tcp config variables that must not change while a message is processed). This one would also conflict with set_delays & commit if it would be done via the fixups. Yes, this is a valid case. We will have to add another flag for this type of fixups. Andrei

On Wednesday 17 February 2010, Miklos Tirpak wrote: Hi Miklos, indeed this is another problem which we've also discussed during the planning for the cfg framework migration work, its present for example in the ratelimit and carrierroute modules. Quite a few kamailio modules implemented also their own version of reload functionality with a FIFO command, e.g. "reload_fifo" in modules/carrierroute/cr_fifo.c. This is more or less a similar use case like the cfg framework represents (atomic reload of a variable), but with a a bit more complicated data structure (route_data_t). So having a generic version for this in the cfg framework would be indeed nice in my opinion. Cheers, Henning

Hi Henning, On 02/17/2010 11:22 AM, Henning Westerholt wrote: the route_data_t structure seems to be the routing data similar to what a route block does in the script, I mean that it is not like a modparam. This is a bit far from the initial concept of the cfg framework but this would not be a problem. In the framework, there are module and core parameters declared by the modules/core and there are cfg drivers that write the parameters. They can work on any backend, file, DB, srcmd... Hence, the drivers or the framework must know the structure of the configuration, i.e. what type of value is stored in which slot. The route_data_t structure is quite complex, the number of carriers and the number of domains is not known in advance, therefore the size of the structure is also unknown. The framework could hardly tell what is stored on a given memory address. The best we could do is to let the carrierroute module write its own configuration and do not touch it by other modules, I mean by the cfg drivers. Actually the framework already supports the void* type that could be used for this purpose (with some enhancements). The module could load the config, allocate the necessary space in shm mem, and link it to the global configuration via the void* pointer. From this point the framework could offer: - consistency: The config would remain the same during a SIP message processing. Even if there is a new config available, it would be used only for the next message routeing. - locking: The carrierroute module should not care about locking the data structures during reading because it is the task of the framework. In fact, the framework supports lockless read because all modifications (except with the atomic flag) copy the entire config block first and modify the clone. This is done for performance reasons because the assumption is that the config rarely changes but it is read many times. This means that even the carrierroute module is not allowed to simply write its data structures. It should always construct a new structure (or clone the existing one) and link the new configuration to the global cfg structure via some interface. So I do not see to much benefit of using the cfg framework in this case because the structure that needs to be stored does not have a fixed size, therefore it is hard to specify for the framework. In this case the carrierroute module would be the only one that can read/write the config which is nothing different from the current situation. Or do you think that the consistency and locking are worth the effort? Regards, Miklos