asterisk

Commit Graph

Author	SHA1	Message	Date
Matthew Jordan	511cf82367	Prevent res_timing_pthread from blocking callers There were several reports of deadlock when using res_timing_pthread. Backtraces indicated that one thread was blocked waiting for the write to the pipe to complete and this thread held the container lock for the timers. Therefore any thread that wanted to create a new timer or read an existing timer would block waiting for either the timer lock or the container lock and deadlock ensued. This patch changes the way the pipe is used to eliminate this source of deadlocks: 1) The pipe is placed in non-blocking mode so that it would never block even if the following changes someone fail... 2) Instead of writing bytes into the pipe for each "tick" that's fired the pipe now has two states--signaled and unsignaled. If signaled, the pipe is hot and any pollers of the read side filedescriptor will be woken up. If unsigned the pipe is idle. This eliminates even the chance of filling up the pipe and reduces the potential overhead of calling unnecessary writes. 3) Since we're tracking the signaled / unsignaled state, we can eliminate the exta poll system call for every firing because we know that there is data to be read. (closes issue ASTERISK-21389) Reported by: Matt Jordan Tested by: Shaun Ruffell, Matt Jordan, Tony Lewis patches: 0001-res_timing_pthread-Reduce-probability-of-deadlocking.patch uploaded by sruffell (License 5417) (closes issue ASTERISK-19754) Reported by: Nikola Ciprich (closes issue ASTERISK-20577) Reported by: Kien Kennedy (closes issue ASTERISK-17436) Reported by: Henry Fernandes (closes issue ASTERISK-17467) Reported by: isrl (closes issue ASTERISK-17458) Reported by: isrl Review: https://reviewboard.asterisk.org/r/2441/ ........ Merged revisions 386109 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 386159 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386160 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	a0c363e227	Refactor ast_timer_ack to return an error and handle the error in timer users Currently, if an acknowledgement of a timer fails Asterisk will not realize that a serious error occurred and will continue attempting to use the timer's file descriptor. This can lead to situations where errors stream to the CLI/log file. This consumes significant resources, masks the actual problem that occurred (whatever caused the timer to fail in the first place), and can leave channels in odd states. This patch propagates the errors in the timing resource modules up through the timer core, and makes users of these timers handle acknowledgement failures. It also adds some defensive coding around the use of timers to prevent using bad file descriptors in off nominal code paths. Note that the patch created by the issue reporter was modified slightly for this commit and backported to 1.8, as it was originally written for Asterisk 10. Review: https://reviewboard.asterisk.org/r/2178/ (issue ASTERISK-20032) Reported by: Jeremiah Gowdy patches: jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358) ........ Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375894 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 375895 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375896 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	d9651f2be9	Fix timing source dependency issues with MOH Prior to this patch, res_musiconhold existed at the same module priority level as the timing sources that it depends on. This would cause a problem when music on hold was reloaded, as the timing source could be changed after res_musiconhold was processed. This patch adds a new module priority level, AST_MODPRI_TIMING, that the various timing modules are now loaded at. This now occurs before loading other resource modules, such that the timing source is guaranteed to be set prior to resolving the timing source dependencies. (closes issue ASTERISK-17474) Reporter: Luke H Tested by: Luke H, Vladimir Mikhelson, zzsurf, Wes Van Tlghem, elguero, Thomas Arimont Patches: asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-1.8.diff uploaded by elguero (License #5026) asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-10.diff uploaded by elguero (License #5026) asterisk-17474-dahdi_timing-infinite-wait-fix_v3.diff uploaded by elguero (License #5026) Review: https://reviewboard.asterisk.org/r/1578/ ........ Merged revisions 349194 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 349195 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349196 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 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	765b275976	Use poll() instead of select() in res_timing_pthread to avoid stack corruption. This code did not properly check FD_SETSIZE to ensure that it did not try to select() on fds that were too large. Switching to poll() removes the limitation on the maximum fd value. (closes issue #15915) Reported by: keiron (closes issue #17187) Reported by: Eddie Edwards (closes issue #16494) Reported by: Hubguru (closes issue #15731) Reported by: flop (closes issue #12917) Reported by: falves11 (closes issue #14920) Reported by: vrban (closes issue #17199) Reported by: aleksey2000 (closes issue #15406) Reported by: kowalma (closes issue #17438) Reported by: dcabot (closes issue #17325) Reported by: glwgoes (closes issue #17118) Reported by: erikje possibly other issues, too ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278465 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	b4e18d5660	Add load priority order, such that preload becomes unnecessary in most cases git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	d532cbcd8a	module load priority This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized. The lower the value, the higher the priority. The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set. If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority on load. Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty. (closes issue #15191) Reported by: alecdavis Tested by: dvossel Review: https://reviewboard.asterisk.org/r/262/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199743 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	04beecc859	Improve handling of trying to ACK too many timer expirations. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198183 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	1fab70a1c6	Resolve issues with choppy sound when using res_timing_pthread. The situation that caused this problem was when continuous mode was being turned on and off while a rate was set for a timing interface. A very easy way to replicate this bug was to do a Playback() from behind a Local channel. In this scenario, a rate gets set on the channel for doing file playback. At the same time, continuous mode gets turned on and off about every 20 ms as frames get queued on to the PBX side channel from the other side of the Local channel. Essentially, this module treated continuous mode and a set rate as mutually exclusive states for the timer to be in. When I dug deep enough, I observed the following pattern: 1) Set timer to tick every 20 ms. 2) Wait almost 20 ms ... 3) Continuous mode gets turned on for a queued up frame 4) Continuous mode gets turned off 5) The timer goes back to its tick per 20 ms. state but starts counting at 0 ms. 6) Goto step 2. Sometimes, res_timing_pthread would make it 20 ms and produce a timer tick, but not most of the time. This is what produced the choppy sound (or sometimes no sound at all). Now, the module treats continuous mode and a set rate as completely independent timer modes. They can be enabled and disabled independently of each other and things work as expected. (closes issue #14412) Reported by: dome Patches: issue14412.diff.txt uploaded by russell (license 2) issue14412-1.6.1.0.diff.txt uploaded by russell (license 2) Tested by: DennisD, russell git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198146 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	5894cefe1f	Trim trailing whitespace so that I can work on this bug without it bothering me. :-) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197960 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	c461d29b0b	Update the timing API to have better support for multiple timing interfaces. 1) Add module use count handling so that timing modules can be unloaded. 2) Implement unload_module() functions for the timing interface modules. 3) Allow multiple timing modules to be loaded, and use the one with the highest priority value. 4) Report which timing module is being use in the "timing test" CLI command. (closes issue #14489) Reported by: russell Review: http://reviewboard.digium.com/r/162/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176666 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	06c56e1381	Fix a problem where continuous mode will get inadvertently get turned off if set_rate() is used while continuous mode was already turned on. (closes issue #13738) Reported by: smurfix Patches: res.patch.fixed uploaded by smurfix (license 547) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163241 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	fd8caa1778	This is basically a complete rollback of r155401, as it was determined that it would be best to maintain API compatibility. Instead, this commit introduces ao2_callback_data() which is functionally identical to ao2_callback() except that it allows you to pass arbitrary data to the callback. Reviewed by Mark Michelson via ReviewBoard: http://reviewboard.digium.com/r/64 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158959 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	0e5367f7eb	Merge the changes from the res_timing_timerfd branch. This provides a new timing interface. In order to use it, you must be running a Linux with a kernel version of 2.6.25 or newer and glibc 2.8 or newer. This timing interface is a good alternative if a timing source is necessary (e.g. for IAX trunking) but DAHDI is otherwise unnecessary for the system. For now, this commit contains the actual work done in the res_timing_timerfd branch. There are no notices in the README or CHANGES files yet, but they will be added in my next commit. The timing API of Asterisk also needs to have a bit of work done with regards to choosing which timing interface to use. This commit makes the choice a build-time decision, by only allowing one of the timer interfaces to be chosen in menuselect. It would be preferable if the choice could be made at run-time, however. The preferred timing interface could be loaded and tested, and if it does not work, choice number two may be used instead. That sort of thing. That is beyond the scope of work in this branch though. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157820 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	30d1744ffc	Add ability to pass arbitrary data to the ao2_callback_fn (called from ao2_callback and ao2_find). Currently, passing OBJ_POINTER to either of these mandates that the passed 'arg' is a hashable object, making searching for an ao2 object based on outside criteria difficult. Reviewed by Russell and Mark M. via ReviewBoard: http://reviewboard.digium.com/r/36/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155401 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	5dfefa5ee6	Merged revisions 140488 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r140488 \| mmichelson \| 2008-08-29 12:34:17 -0500 (Fri, 29 Aug 2008) \| 22 lines After working on the ao2_containers branch, I noticed something a bit strange. In all cases where we provide a callback function to ao2_container_alloc, the callback function would only return 0 or CMP_MATCH. After inspecting the ao2_callback() code carefully, I found that if you're only looking for one specific item, then you should return CMP_MATCH \| CMP_STOP. Otherwise, astobj2 will continue traversing the current bucket until the end searching for more matches. In cases like chan_iax2 where in 1.4, all the peers are shoved into a single bucket, this makes for potentially terrible performance since the entire bucket will be traversed even if the peer is one of the first ones come across in the bucket. All the changes I have made were for cases where the callback function defined was passed to ao2_container_alloc so that calls to ao2_find could find a unique instance of whatever object was being stored in the container. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140489 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	357bf3e90b	All of the res/ stuff (other than res_jabber) from the RSW branch. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@137028 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	02b1317d0f	- add get_max_rate timing API call - change ast_settimeout() to honor max rate in edge cases of file playback (this will make some warning messages go away at the end of playing back a file) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125332 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	ed289fd3aa	fix a memory leak. (inspired by, and potentially fixes issue #12917) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124798 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	fa4bce7c43	- Make res_timing_pthread allow a max rate of 100/sec instead of 50/sec - change the "timing test" CLI command to let you specify a timing rate to test git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124023 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	5aeb6a6cbb	Fix the check against the max supported rate git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123393 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	9a301b9f20	Merge res_timing_pthread. This is a timing interface for Asterisk that does not require DAHDI. It's called "pthread" because it uses a pthread API call in the timing thread for sleeping and ensuring we wake up at an appropriate time. I wasn't sure what else to call it. :) The timing API requires a file descriptor that can be polled on. So, when you open a timer, this module creates a pipe and returns the read end of the pipe. There is a background thread that wakes up every 10ms and checks to see if any of the currently open timers need a 'tick' and writes to the appropriate pipe. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122928 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago

22 Commits (b7ec25ec2e98e5e4bb26edacb855602541e30b7f)