[asterisk-dev] [Code Review] 3184: Create sorcery instance registry

[George Joseph]

> On Feb. 6, 2014, 1:01 p.m., Joshua Colp wrote:
> > branches/12/tests/test_sorcery.c, line 362
> > <https://reviewboard.asterisk.org/r/3184/diff/4/?file=53657#file53657line362>
> >
> >     Er, do you mean you are unreffing an object that is already destroyed? If so setting the variables to NULL will prevent that. Once this clarification is provided this'll be good!

Duh.  Low blood sugar.


- George


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3184/#review10802
-----------------------------------------------------------


On Feb. 6, 2014, 12:55 p.m., George Joseph wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3184/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2014, 12:55 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22537
>     https://issues.asterisk.org/jira/browse/ASTERISK-22537
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Create sorcery instance registry as a precursor to creating a generic dialplan function that can retrieve parameters from a sorcery-based config file.
> 
> ast_sorcery_init now creates a hashtab as a registry.
> ast_sorcery_open now checks the hashtab for an existing sorcery instance matching the caller's module name.  If it finds one, it bumps the refcount and returns it.  If not, it creates a new sorcery instance, adds it to the hashtab, then returns it.
> ast_sorcery_retrieve_by_module_name is a new function that does a hashtab lookup by module name.  It can be called by the future dialplan function.
> 
> A side effect of this patch is that a module can only have 1 sorcery instance (because it's the key for the hashtab).  res_pjsip/config_system needed a small change to share the main res_pjsip sorcery instance.
> 
> 
> Diffs
> -----
> 
>   branches/12/tests/test_sorcery.c 407566 
>   branches/12/res/res_pjsip/include/res_pjsip_private.h 407566 
>   branches/12/res/res_pjsip/config_system.c 407566 
>   branches/12/res/res_pjsip.c 407566 
>   branches/12/main/sorcery.c 407566 
>   branches/12/include/asterisk/sorcery.h 407566 
> 
> Diff: https://reviewboard.asterisk.org/r/3184/diff/
> 
> 
> Testing
> -------
> 
> Made sure that users of sorcery (mostly res_pjsip) continued to load their configs correctly.
> Made sure there were no ill effects on res_pjsip from config_system sharing the same sorcery instance as the rest of the pjsip infrastructure.
> Made sure that config_system was properly marked as 'not reloadable' and that it was maintaining it's original values when res_pjsip was reloaded.
> 
> 
> ernie*CLI> test execute category /main/sorcery/
> Running all available tests matching category /main/sorcery/
> 
> START  /main/sorcery/ - configuration_file_wizard_retrieve_multiple_all 
> END    /main/sorcery/ - configuration_file_wizard_retrieve_multiple_all Time: <1ms Result: PASS
> [snip]
> START  /main/sorcery/ - open 
> END    /main/sorcery/ - open Time: <1ms Result: PASS
> START  /main/sorcery/ - wizard_registration 
> END    /main/sorcery/ - wizard_registration Time: <1ms Result: PASS
> 
> 43 Test(s) Executed  43 Passed  0 Failed
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140206/e2cecb43/attachment-0001.html>