aboutsummaryrefslogtreecommitdiffstats
path: root/main/pbx.c
AgeCommit message (Collapse)AuthorFilesLines
2007-11-24closes issue #11363; where the pattern _20x. buried in an included context, ↵murf1-87/+212
didn't match 2012; There were a small set of problems to fix: 1. I needed NOT to score patterns unless you are at the end of the data string. 2. Capital N,X,Z and small n,x,z are OK in patterns. I canonicalize the patterns in the trie to caps. 3. When a pattern ends with dot or exclamation, CANMATCH/MATCHMORE should always report this pattern, no matter the length. With this commit, I also supplied the wish of Luigi, where the user can select which pattern matching algorithm to use, the old (legacy) pattern matcher, or the new, trie based matcher. The OLD matcher is the default. A new [general] section variable, extenpatternmatchnew, is added to the extensions.conf, and the example config has it set to false. If true, the new matcher is used. In all other respects, the context/exten structs are the same; the tries and hashtabs are formed, but in the new mode the tries are not used. A new CLI command 'dialplan set extenpatternmatch true/false' is provided to allow switching at run time. I beg users that are forced to return to the old matcher to please report the reason in the bug tracker. Measured the speed benefit of the new matcher against an impossibly large context with 10,000 extensions: the new matcher is 374 times faster. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89547 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-21remove a bunch of useless #include "options.h"rizzo1-1/+0
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89511 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-21closes issue #11290; the proposed patch was a good guess, and would solve ↵murf1-43/+93
the bug to some extent, but was really masking the real issue, that there were bad entries in the table. This fix removes the condition that the hashtab updates be done on exten removal only when the pattern_tree was present, which is silly. The operations that apply to the pattern tree are instead made conditional. Also, threw back in routines that kpfleming deleted because of probs in the 64-bit world. Tested on both 32 and 64-bit machines (compile). Tested the reload problem with over 20 reloads, and no problems. If you find more problems, please reopen 11290. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89505 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-21I introduced a deadlock avoidance into 1.4, which I attempted to port to ↵mmichelson1-2/+0
trunk as well. Unfortunately, since trunk uses read/write locks for the context lock, it means that I have actually *introduced* a deadlock condition since they are not recursive. Removing this change for now and will look into introducing a different one. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89483 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-21remove some debugging code that doesn't compile on 64-bit platformskpfleming1-60/+15
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89480 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-21A free in add_pri was ultimately the source of the grief we were having with ↵murf1-21/+78
parking. This set of changes fixes that problem, and introduces some more error messages, and puts debugs into ifdefs for what could be short-term usage. Txs to Terry W. for his help, guidance, and especially patience. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89474 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-20move asterisk/paths.h outside asterisk.h and into those filesrizzo1-1/+1
who really need it. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89466 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-20move internal function declarations to include/asterisk/_private.hrizzo1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89465 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-20Merged revisions 89457 via svnmerge from mmichelson1-0/+2
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r89457 | mmichelson | 2007-11-20 11:50:31 -0600 (Tue, 20 Nov 2007) | 9 lines According to comments in main/pbx.c, it is essential that if we are going to lock the conlock as well as the hints lock, it must be locked in that respective order. In order to prevent a potential deadlock, we need to lock the conlock prior to locking the hints lock in ast_hint_state_changed (see the call stack example on issue #11323 for how this can happen). (closes issue #11323, reported by eelcob, suggestion for patch by eelcob, patch by me) ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89458 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-20Get rid of some debug messages in pbx.cmurf1-9/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89442 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-19These changes were made in response to niklas@tese.se's letter of ↵murf1-18/+61
11-17-2007, where he had 20 and 201 in two different contexts, included in the same context. In that particular case, we were behaving the same as 1.4, but after experimenting, I quickly found that if 20 and 201 were in the same extension, 1.4 would return 201, and this code returns 20. These changes now enable the current code to replicate the behavior of 1.4 in respect to MATCHMORE in cases like this. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89438 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-19another bunch of include removals (errno.h and asterisk/logger.h)rizzo1-2/+0
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89425 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-19a correction to code involved in an extension removalmurf1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89422 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-17a quick fix to pbx_dundi.c to make it so it will compile. Hope I did the ↵murf1-4/+26
right thing. And some additions to removal of extens to take care of hashtab pointers in all cases. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89388 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-16My goodness, haven't handled an extension deletion. Add code to ↵murf1-10/+62
ast_context_remove_extension2() to remove an extension from the trie. Done by marking it deleted. The scoreboard won't update for it any more. Also, a couple of calls to insert hashtab had a spurious ->exten, which was removed. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89346 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-16Start untangling header inclusion in a way that does not affectrizzo1-5/+0
build times - tested, there is no measureable difference before and after this commit. In this change: use asterisk/compat.h to include a small set of system headers: inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h, stdlib.h, alloca.h, stdio.h Where available, the inclusion is conditional on HAVE_FOO_H as determined by autoconf. Normally, source files should not include any of the above system headers, and instead use either "asterisk.h" or "asterisk/compat.h" which does it better. For the time being I have left alone second-level directories (main/db1-ast, etc.). git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89333 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-16This corrects a hashtab removal, given a bad argumentmurf1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89330 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-16This fixes a problem with pattern ranges; and corrects a situation in ↵murf1-2/+6
res_features, where an extension would be created with the name Zap/51, as an example. THe / is bad because it would tend to mean that the 51 is to be cid matched. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89329 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-15Get rid of a previously missed ast_log call for debug, no longer nec.murf1-1/+0
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89295 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-15Perhaps I went overboard on initializing things. I can remove unnecc. stuff ↵murf1-14/+21
later. A few bug fixes. Killing small bugs on the way to killing bigger ones. Removed locking on hashtabs; there's plenty of locks already being taken. A small bug in the root_tree hashtab compare func. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89294 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-15Had trouble playing with parking; spent a long time trying to reason out ↵murf1-1/+4
MATCHMORE mode. made these updates and xfers on zaptel lines seem to work ok now git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89277 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-14Rescaled the weights of the patterns to give something more independent of ↵murf1-14/+33
pattern length; and make . less likely to win. Question: which should win for 14102241145-- _1xxxxxxx. or _XXXXXXXXXXX -- right now, the pure X pattern will win. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89272 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-14A further problem highlighted by 11233 has been resolved; a certain ↵murf1-5/+5
combination of patterns in a certain order, led to a malformed trie, due to a ptr not being initialized in the loop. Also, some tree printing prettifications. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89271 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-14use simpler technique for removing known entries from listskpfleming1-9/+3
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89259 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-13This hopefully will fix the re-opened 11233. Hadn't covered the case of a ↵murf1-1/+1
context with no patterns. (blush) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89257 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-13closes issue #11233 -- where some fine points in the algorithm to build the ↵murf1-3/+6
tree needed to be corrected. Many thanks for the test case, jtodd git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89256 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-12Merged revisions 89194 via svnmerge from qwell1-1/+1
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r89194 | qwell | 2007-11-12 14:46:52 -0600 (Mon, 12 Nov 2007) | 1 line Fix a typo pointed out by De_Mon on #asterisk-dev ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89195 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-12Based on a note in asterisk-dev by Brian Capouch, I determined I too ↵murf1-1/+2
agressive in not initializing arrays passed to pbx_substitute_variables_xxxx; I reviewed the code (again) and hopefully found every possible spot where substitute_variables is called conditionally, and made sure the char array involved was set to a null string. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89186 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-09This is the perhaps the biggest, boldest, most daring change I've ever ↵murf1-43/+802
committed to trunk. Forgive me in advance any disruption this may cause, and please, report any problems via the bugtracker. The upside is that this can speed up large dialplans by 20 times (or more). Context, extension, and priority matching are all fairly constant-time searches. I introduce here my hashtables (hashtabs), and a regression for them. I would have used the ast_obj2 tables, but mine are resizeable, and don't need the object destruction capability. The hashtab stuff is well tested and stable. I introduce a data structure, a trie, for extension pattern matching, in which knowledge of all patterns is accumulated, and all matches can be found via a single traversal of the tree. This is per-context. The trie is formed on the first lookup attempt, and stored in the context for future lookups. Destruction routines are in place for hashtabs and the pattern match trie. You can see the contents of the pattern match trie by using the 'dialplan show' cli command when 'core set debug' has been done to put it in debug mode. The pattern tree traversal only traverses those parts of the tree that are interesting. It uses a scoreboard sort of approach to find the best match. The speed of the traversal is more a function of the length of the pattern than the number of patterns in the tree. The tree also contains the CID matching patterns. See the source code comments for details on how everything works. I believe the approach general enough that any issues that might come up involving fine points in the pattern matching algorithm, can be solved by just tweaking things. We shall see. The current pattern matcher is fairly involved, and replicating every nuance of it is difficult. If you find and report problems, I will try to resolve than as quickly as I can. The trie and hashtabs are added to the existing context and exten structs, and none of the old machinery has been removed for the sake of the multitude of functions that use them. In the future, we can (maybe) weed out the linked lists and save some space. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89129 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-08improve linked-list macros in two ways:kpfleming1-12/+12
- the *_CURRENT macros no longer need the list head pointer argument - add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89106 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06Fix up some PBX logic that became broken. The code would exit prematurely ↵file1-25/+25
when it should have been collecting more digits. (closes issue #11175) Reported by: pj git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89072 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06"show application <foo>" changes for clarity.mmichelson1-3/+4
(closes issue #11171, reported and patched by blitzrage) Many thanks! git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89044 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-06Merged revisions 88805 via svnmerge from russell1-11/+37
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r88805 | russell | 2007-11-05 16:07:54 -0600 (Mon, 05 Nov 2007) | 12 lines After seeing crashes related to channel variables, I went looking around at the ways that channel variables are handled. In general, they were not handled in a thread-safe way. The channel _must_ be locked when reading or writing from/to the channel variable list. What I have done to improve this situation is to make pbx_builtin_setvar_helper() and friends lock the channel when doing their thing. Asterisk API calls almost all lock the channel for you as necessary, but this family of functions did not. (closes issue #10923, reported by atis) (closes issue #11159, reported by 850t) ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@88934 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-04Simplify the implementation and the API for stringfields;rizzo1-1/+1
details and examples are in include/asterisk/stringfields.h. Not applicable to older branches except for 1.4 which will receive a fix for the routines that free memory pools. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@88454 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-02Add pbx_lua as a method of doing extensionstilghman1-0/+5
Reported by: mnicholson Patch by: mnicholson Closes issue #11140 git-svn-id: http://svn.digium.com/svn/asterisk/trunk@88250 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-02'h' extension doesn't execute past first prioritytilghman1-1/+1
Reported by: dimas Patch by: dimas Closes bug #11146 git-svn-id: http://svn.digium.com/svn/asterisk/trunk@88209 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-01Modify WaitExten to include an optional dialtonetilghman1-2/+13
Closes issue #10783 git-svn-id: http://svn.digium.com/svn/asterisk/trunk@88183 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-01This commits the performance mods that give the priority processing engine ↵murf1-73/+72
in the pbx, a 25-30% speed boost. The two updates used, are, first, to merge the ast_exists_extension() and the ast_spawn_extension() where they are called sequentially in a loop in the code, into a slightly upgraded version of ast_spawn_extension(), with a few extra args; and, second, I modified the substitute_variables_helper_full, so it zeroes out the byte after the evaluated string instead of demanding you pre-zero the buffer; I also went thru the code and removed the code that zeroed this buffer before every call to the substitute_variables_helper_full. The first fix provides about a 9% speedup, and the second the rest. These figures come from the 'PIPS' benchmark I describe in blogs, conf. reports, etc. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@88166 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-01Drop any more references to type in the Exception dialplan function.file1-9/+9
(closes issue #11134) Reported by: blitzrage Patches: exception_patch.txt uploaded by blitzrage (license 10) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87953 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-31Optimize pbx_substitute_variablestilghman1-1/+6
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87811 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-30Update documentation to give an example of how to use the return status of ↵qwell1-1/+2
RaiseException Closes issue #11117, patch by blitzrage (yay blitzrage) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87626 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-30The priority gets incremented after raising an exception, so the priority ↵mmichelson1-1/+1
should be set to 0 git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87608 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-30Jumped the gun a bit in the RaiseException app. It would always return -1mmichelson1-1/+1
since it checked for the existence of something that will never exist. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87573 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-22Switch from AST_CLI (formerly NEW_CLI) to AST_CLI_DEFINE, since the former ↵qwell1-9/+9
didn't make much sense git-svn-id: http://svn.digium.com/svn/asterisk/trunk@86820 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-19Convert NEW_CLI to AST_CLI.qwell1-9/+9
Closes issue #11039, as suggested by seanbright. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@86536 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-11Merged revisions 85356 via svnmerge from tilghman1-2/+3
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r85356 | tilghman | 2007-10-10 23:35:33 -0500 (Wed, 10 Oct 2007) | 2 lines A dollar sign by itself, not indicating a start of a variable or expression prematurely ends substitution (closes issue #10939) ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@85357 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-04Don't register the exception function with module information. Since it is ↵file1-1/+1
in the core there is none and it will explode. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@84613 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-03Create a universal exception handling extension, "e" (closes issue #9785)tilghman1-5/+132
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@84580 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-02Add MSet for people who prefer the old, deprecated syntax of Set (Closes ↵tilghman1-1/+46
issue #10549) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@84405 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-18(issue #10724)qwell1-220/+236
Reported by: eliel Patches: res_features.c.patch uploaded by eliel (license 64) res_agi.c.patch uploaded by seanbright (license 71) res_musiconhold.c.patch uploaded by seanbright (license 71) pbx.c.patch uploaded by moy (license 222) logger.c.patch uploaded by moy (license 222) frame.c.patch uploaded by moy (license 222) manager.c.patch uploaded by moy (license 222) http.c.patch uploaded by moy (license 222) dnsmgr.c.patch uploaded by moy (license 222) res_realtime.c.patch uploaded by eliel (license 64) res_odbc.c.patch uploaded by seanbright (license 71) res_jabber.c.patch uploaded by eliel (license 64) chan_local.c.patch uploaded by eliel (license 64) chan_agent.c.patch uploaded by eliel (license 64) chan_alsa.c.patch uploaded by eliel (license 64) chan_features.c.patch uploaded by eliel (license 64) chan_sip.c.patch uploaded by eliel (license 64) RollUp.1.patch (includes all of the above patches) uploaded by seanbright (license 71) Convert many CLI commands to the NEW_CLI format. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@82930 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-04 00:34:06 +0000