[asterisk-dev] bug 6002 fix for review

[Steve Murphy]

Hello! 

I think I have completed the fix for bug 6002, and anyone interested is 
invited to review and/or test the code. I explained in a previous mailing 
what the algorithm would do, so you may wish to review the bug: 

http://bugs.digium.com/view.php?id=6002 

And my earlier letter: 

http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html 

The branch containing the fixes for 6002: 

http://svn.digium.com/svn/asterisk/team/murf/bug6002 


The fixes themselves involve changes to these files: 

Index: pbx/pbx_config.c 
Index: pbx/pbx_ael.c 
Index: channels/chan_zap.c 
Index: channels/chan_sip.c 
Index: channels/chan_iax2.c 
Index: channels/chan_skinny.c 
Index: channels/chan_local.c 
Index: apps/app_meetme.c 
Index: apps/app_dial.c 
Index: apps/app_queue.c 
Index: include/asterisk/_private.h 
Index: include/asterisk/pbx.h 
Index: include/asterisk/pval.h 
Index: main/channel.c 
Index: main/features.c 
Index: main/asterisk.c 
Index: main/autoservice.c 
Index: main/pbx.c 
Index: res/ael/pval.c 
Index: res/ael/ael.tab.c 
Index: res/ael/ael.y 
Index: res/ael/ael_lex.c 
Index: res/ael/ael.tab.h 
Index: res/ael/ael.flex 
Index: utils/ael_main.c 
Index: utils/extconf.c 
Index: utils/conf2ael.c 
Index: utils/Makefile 

The scope of the fixes seems a bit extensive, but because I decided it would be better 
to modify the interface to the AEL parser, the stuff in utils was affected, as well as the stuff in 
res/ael. 

All aps and channel drivers that added contexts or extensions to the 
dialplan had to be slightly tweaked as to how they did it. 

Results: 

I wanted to reduce the time that the dialplan was locked during a merge_contexts_and_delete() 
call. In this, I was successful. For my tiny test dialplan, I reduced the write-lock time from 
roughly 43 microseconds, to 3-6 microseconds. 

You may not be very impressed that I could reduce the lock-down time from 43 to 3-6 microseconds, 
but you have to realize that this is a SMALL dialplan. I dialplan with 10-20 K priorities will have 
substantially larger lock-down times. Especially if it has lots and lots of contexts. But it will always 
have a lock-down time of 3-6 microseconds. 

Well, I take that back. Actually, I've reduced the lock-down time to the time to change 2 pointers, 
and save, and then restore the hint data. If you have a lot of hints, that will slow down the merge 
time. 

Now, also keep in mind that the new algorithm requires a lot more processing. The bulk of it, though, is done outside the lock-down period. For my small test dialplan, the total time to perform merge_contexts_and_delete() is about 31000 microseconds (about 700 times slower). Again, 
only 3-6 of those microseconds were spent locked down, so (at least to me) the extra time 
is not spent in a critical path, so it's not a big deal. 

By the way, my tiny test dialplan is 47 contexts, 240 extensions, 624 priorities, most of them in AEL, 
about 15 or so contexts in extensions.conf. 

I've thrashed this code with reloads ("dialplan reload", and "ael reload"), and "stop gracefully". 
I've spec'd :"regcontext=xxx" in sip.conf, and also had the xxx context in AEL. I've verified that 
priorities registered in the name of "sip", but attached to a context with registrar of "pbx_ael" were not 
lost when AEL reloaded. Duplicate contexts are no longer possible. 

Any other acid tests you'd like to perform, now is the time, or suffer when this stuff gets merged into trunk. 

murf 

-- 
Steve Murphy 
Software Developer 
Digium 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080303/18b61de6/attachment.htm