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@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