And a bug fix for the previous news entry - see what happens when I take too long to post the news! :)

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

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

Comments (Click to post)

Name:
Subject:
Website:
Message: