8 Commits (a66fa4db24553d6ec6c8978c528081a94b1715a1)

Author	SHA1	Message	Date
Corey Farrell	0d266cbe02	Stasis: Fix unsafe use of stasis_unsubscribe in modules. ... Many uses of stasis_unsubscribe in modules can be reached through unload. These have been switched to stasis_unsubscribe_and_join. Some subscription callbacks do nothing, for these I've created a noop callback function in stasis.c. This is used by some modules that monitor MWI topics in order to enable cache, since the callback does not become invalid after dlclose it is safe to use stasis_unsubscribe on these, even during module unload. ASTERISK-25121 #close Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c	10 years ago
Diederik de Groot	d6dfc85666	Clang: Fix some more tautological-compare warnings. ... clang can warn about a so called tautological-compare, when it finds comparisons which are logically always true, and are therefor deemed unnecessary. Exanple: unsigned int x = 4; if (x > 0) // x is always going to be bigger than 0 Enum Case: Each enumeration is its own type. Enums are an integer type but they do not have to be *signed*. C leaves it up to the compiler as an implementation option what to consider the integer type of a particu- lar enumeration is. Gcc treats an enum without negative values as an int while clang treats this enum as an unsigned int. rmudgett & mmichelson: cast the enum to (unsigned int) in assert. The cast does have an effect. For gcc, which seems to treat all enums as int, the cast to unsigned int will eliminate the possibility of negative values being allowed. For clang, which seems to treat enums without any negative members as unsigned int, the cast will have no effect. If for some reason in the future a negative value is ever added to the enum the assert will still catch the negative value. ASTERISK-24917 Change-Id: Ief23ef68916192b9b72dabe702b543ecfeca0b62	10 years ago
David M. Lee	2de42c2a25	Multiple revisions 399887,400138,400178,400180-400181 ... ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines Optimize how Stasis forwards are dispatched This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines Remove dispatch object allocation from Stasis publishing While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kevin Harwell	16b8d0cb5a	Fix various memory leaks ... main/config.c - cleanup cache fie includes res/res_security_log.c - unregister logger level channesl/chan_sip.c - cleanup io context and notify_types main/translator.c - cleanup at shutdown main/named_acl.c - cleanup cli commands main/indications.c - ast_get_indication_tone() unref default_tone_zone if used (closes issues ASTERISK-22378) Reported by: Corey Farrell Patches: config_shutdown.patch uploaded by coreyfarrell (license 5909) res_security_log.patch uploaded by coreyfarrell (license 5909) chan_sip-11.patch uploaded by coreyfarrell (license 5909) indications_refleak.patch uploaded by coreyfarrell (license 5909) named_acl-cli_unreg-trunk.patch uploaded by coreyfarrell (license 5909) translate_shutdown.patch uploaded by coreyfarrell (license 5909) ........ Merged revisions 398102 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 398103 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 398116 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398124 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	59753b1ea1	Strip down the old event system ... This removes unused code, event types, IE pltypes, and event IE types where possible and makes several functions private that were once public. This includes a renumbering of the remaining event and IE types which breaks binary compatibility with previous versions. The last remaining consumers of the old event system (or parts thereof) are main/security_events.c, res/res_security_log.c, tests/test_cel.c, tests/test_event.c, main/cel.c, and the CEL backends. Review: https://reviewboard.asterisk.org/r/2703/ (closes issue ASTERISK-22139) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	b90bba7a30	Stasis: Update security events to use Stasis ... Also moves ACL messages to the security topic and gets rid of the ACL topic (closes issue ASTERISK-21103) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2496/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388975 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Leif Madsen	a525edea59	Merged revisions 328247 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.10 ................ r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines Merged revisions 328209 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines Introduce <support_level> tags in MODULEINFO. This change introduces MODULEINFO into many modules in Asterisk in order to show the community support level for those modules. This is used by changes committed to menuselect by Russell Bryant recently (r917 in menuselect). More information about the support level types and what they mean is available on the wiki at https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328259 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Russell Bryant	4cf8a968fd	Add an API for reporting security events, and a security event logging module. ... This commit introduces the security events API. This API is to be used by Asterisk components to report events that have security implications. A simple example is when a connection is made but fails authentication. These events can be used by external tools manipulate firewall rules or something similar after detecting unusual activity based on security events. Inside of Asterisk, the events go through the ast_event API. This means that they have a binary encoding, and it is easy to write code to subscribe to these events and do something with them. One module is provided that is a subscriber to these events - res_security_log. This module turns security events into a parseable text format and sends them to the "security" logger level. Using logger.conf, these log entries may be sent to a file, or to syslog. One service, AMI, has been fully updated for reporting security events. AMI was chosen as it was a fairly straight forward service to convert. The next target will be chan_sip. That will be more complicated and will be done as its own project as the next phase of security events work. For more information on the security events framework, see the documentation generated from doc/tex/. "make asterisk.pdf" Review: https://reviewboard.asterisk.org/r/273/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206021 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago