summaryrefslogtreecommitdiff
path: root/include/asterisk/hashtab.h
AgeCommit message (Collapse)Author
2018-03-01core: Remove ABI effects of MALLOC_DEBUG.Richard Mudgett
This allows asterisk to be compiled with MALLOC_DEBUG to load modules built without MALLOC_DEBUG. Now pre-compiled third-party modules will still work regardless of MALLOC_DEBUG being enabled or not. Change-Id: Ic07ad80b2c2df894db984cf27b16a69383ce0e10
2016-08-19Fix checks for allocation debugging.Corey Farrell
MALLOC_DEBUG should not be used to check if debugging is actually enabled, __AST_DEBUG_MALLOC should be used instead. MALLOC_DEBUG only indicates that debugging is requested, __AST_DEBUG_MALLOC indicates it is active. Change-Id: I3ce9cdb6ec91b74ee1302941328462231be1ea53
2012-11-16Migrate hashtest/hashtest2 to be unit tests.David M. Lee
Both hashtest and hashtest2 are manual testing apps that thrash hash tables (hashtab and ao2 containers, respectively), by spinning up several threads that randomly insert, delete, lookup and iterate over the hash table. If the app doesn't crash, the hash table probably passes the test. Those utils are not a part of the typical Asterisk build, so they do not usually get compiled. This all makes them less that useful. This patch removes those manual test programs and replaces them with Asterisk unit test modules (test_{hashtab,astobj2}_thrash.so). It also attempts to make the tests more deterministic. * Rather than spinning up some number of threads that operate on the hash table randomly, spin up four threads that concurrenly add, remove, lookup and iterate over the hash table. * Each thread checks the state of the hash table both during and after execution, and indicates a test failure if things are not as expected. * Each thread times out after 60 seconds to prevent deadlocking the unit test run. (closes issue ASTERISK-20505) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2189/ ........ Merged revisions 376306 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 376315 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 376339 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-11Add MALLOC_DEBUG to various utility APIs, so that memory leaks can be ↵Tilghman Lesher
tracked back to their source. (related to issue #14636) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-21Trailing whitespace, minor coding guideline fixes, and start beefing up theSean Bright
hashtab documentation a bit. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-14Add additional memory debugging to several core APIs, and fix several memoryTilghman Lesher
leaks found with these changes. (Closes issue #13505, closes issue #13543) Reported by: mav3rick, triccyx Patches: 20081001__bug13505.diff.txt uploaded by Corydon76 (license 14) Tested by: mav3rick, triccyx git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-25I added a little verbage to hashtab for the hashtab_destroy func.Steve Murphy
It was pretty sparsely documented. This update fleshes out the pbx_lua module, to add the switch statements to the extensions in the extensions.lua file, as well as removing them when the module is unloaded. Many thanks to Matt Nicholson for his fine contribution! git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-11A lot of doxygen updatesOlle Johansson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92285 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-14Fix up various coding guidelines issues ...Russell Bryant
- handle memory allocation failures - add an ast_ prefix to a publicly exported function - put curly braces in the right places - add a bunch of spaces where they should be be used git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-12Thanks to snuffy for this doxygen update to hashtab.h; closes issue #11223Steve Murphy
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-12Thanks to snuff-work, who brought up that these fixes might need to be made.Steve Murphy
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-09This is the perhaps the biggest, boldest, most daring change I've ever ↵Steve Murphy
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: https://origsvn.digium.com/svn/asterisk/trunk@89129 65c4cc65-6c06-0410-ace0-fbb531ad65f3