[SR-Users] Simulating kamailio config flows

[Daniel-Constantin Mierla]

On 5/24/13 12:00 AM, Daniel-Constantin Mierla wrote:
>
> On 5/23/13 10:45 PM, Victor Seva wrote:
>> 2013/5/23 Daniel-Constantin Mierla <miconda at gmail.com>:
>>> First a general recommendation: try to avoid patching core that much 
>>> for
>>> non-common use cases.
>> Sure. I was just trying to see how this could be done. I don't want to
>> mess with the core. :-)
>>
>> [snip]
>>
>>> At this moment, I think a good solution could be:
>> [snip]
>>> - update the interpreter to use pv cache instead of own spec per pv 
>>> (I can
>>> do it, being in my list and hopefully is no big change)
>> I will try to do it myself just to get familliar with this area. Let's
>> see how it goes.
>>
>>> - if this feature is enabled in debugger module, it will create a 
>>> hash table
>>> where to index pv set functions by pointer and point to the cache item
>>> - this index has to be created in child_init with rank PROC_INIT to 
>>> be sure
>>> all pvs were resolved to cache item
>> Sorry. But I don't get this. Can you, please, explain me the rationale
>> behind this hash table?.
> First about the pv_cache - it is a hash table with specs of pvs used 
> in config file. Not all pvs are using the cache yet, but should be 
> migrate to it. The nebefit is that if a same pv is used more than one, 
> only one spec is stored in cache. For example, if there will be no pv 
> cache used, if you have 10 of $ru, used memory is 20*sizeof(pv_spec). 
> If pv cache will be used everywhere, the will be one pv_spec and 10 
> pointers to it. Because the size of pvspec is much larger than pointer 
> size, it obviously results in lower memory usage. More that that, if 
> one needs to parse a pv name at runtime, will not allocate memory each 
> time, but only first time when added to cache, avoiding memory leak 
> because some pv_spec have dynamic structure and no free function.
>
> The pv_cache contains items of:
>
> {
>   pvname
>   pvspec
>   ...
> }
>
> A lookup by pvname in pv_cache returns the address of pvspec in the 
> above structure.
>
> If the config interpreter uses pv_cache, you get access to pointer of 
> pvspec field. You can use structure offset to get the start of the 
> item and from there pvname,

> but because cache is not used name, 

wanted to say: "but because the cache is not used everywhere" -- also 
some modules use core actions from inside the code, therefore you search 
for pointer in cache, you don't find, then print $unknown...


> what you get from config interpreter can be a standalone pointer and 
> will result in segmentation fault.
>
> You can lookup the pointer in the pv_cache, by iterating through all 
> slots until a match. Could be good/fast enough for debugging. I was 
> thinking of using a hash table to index needed pv_cache items.
>
> A virtual example of config:
>
> $x1 = $x2 + $x3 + $x4;
> xlog("$x5 $x6 $x7");
> $x8 = $x1 + $x9;
> $x1 = $x10 + $x11 + $x4;
>
> The pv cache will have 11 items, but you need to know only the name of 
> two pvs: $x1 and $x2, because the others are not assigned. To speed 
> up, you look first for the pointer to $x1 on debugger hash table, it 
> is not found, iterate in pv cache, find it and store the pointer in 
> debugger hash table so next time you need it, you find it quickly.
>
> Cheers,
> Daniel
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *