[asterisk-dev] bug 6002 fix for review
murf at digium.com
Mon Mar 3 16:58:16 CST 2008
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:
And my earlier letter:
The branch containing the fixes for 6002:
The fixes themselves involve changes to these files:
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
All aps and channel drivers that added contexts or extensions to the
dialplan had to be slightly tweaked as to how they did it.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-dev