aboutsummaryrefslogtreecommitdiffstats
path: root/res/res_timing_timerfd.c
AgeCommit message (Collapse)AuthorFilesLines
2011-01-19Merged revisions 302462 via svnmerge from pabelanger1-1/+1
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r302462 | pabelanger | 2011-01-19 12:09:35 -0500 (Wed, 19 Jan 2011) | 9 lines Merged revisions 302461 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r302461 | pabelanger | 2011-01-19 12:08:01 -0500 (Wed, 19 Jan 2011) | 2 lines Handle 'Resource temporarily unavailable' error more gracefully. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@302463 f38db490-d61c-443f-a65b-d21fe96a405b
2010-11-08Merged revisions 294313 via svnmerge from jpeeler1-0/+1
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r294313 | jpeeler | 2010-11-08 16:32:13 -0600 (Mon, 08 Nov 2010) | 9 lines Merged revisions 294312 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r294312 | jpeeler | 2010-11-08 16:30:49 -0600 (Mon, 08 Nov 2010) | 1 line add missing unlock not present in 294277 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@294314 f38db490-d61c-443f-a65b-d21fe96a405b
2010-11-08Merged revisions 294278 via svnmerge from jpeeler1-0/+9
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines Merged revisions 294277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines Fix playback failure when using IAX with the timerfd module. To fix this issue the alert pipe will now be used when the timerfd module is in use. There appeared to be a race that was not solved by adding locking in the timerfd module, but needed to be there anyway. The race was between the timer being put in non-continuous mode in ast_read on the channel thread and the IAX frame scheduler queuing a frame which would enable continuous mode before the non-continuous mode event was read. This race for now is simply avoided. (closes issue #18110) Reported by: tpanton Tested by: tpanton I put tested by tpanton because it was tested on his hardware. Thanks for the remote access to debug this issue! ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@294279 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-20Add load priority order, such that preload becomes unnecessary in most casestilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@278132 f38db490-d61c-443f-a65b-d21fe96a405b
2010-01-15Clarify error message in res_timing_timerfd.seanbright1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@240505 f38db490-d61c-443f-a65b-d21fe96a405b
2010-01-14If we aren't running on a machine that support CLOCK_MONOTONIC, don't load.seanbright1-0/+10
Group developed and tested by seanbright, Corydon76, Kobaz, and Amorsen. git-svn-id: http://svn.digium.com/svn/asterisk/trunk@240226 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-09module load prioritydvossel1-1/+5
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: http://svn.digium.com/svn/asterisk/trunk@199743 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-11Fix some timer state corruption.russell1-2/+4
In res_timer_timerfd, handle the case that set_rate gets called while a timer is still in continuous mode. In this case, we want to remember the configured rate, but not actually set it until continuous mode has been disabled. Thanks to dvossel for finding and helping to debug the problem. (closes issue #15080) Reported by: dvossel Tested by: dvossel git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193718 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-02Fix a reference leak in timerfd_set_rate().russell1-1/+6
(found during a debugging session with dvossel and mmichelson.) git-svn-id: http://svn.digium.com/svn/asterisk/trunk@179465 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-17Update the timing API to have better support for multiple timing interfaces.russell1-10/+13
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: http://svn.digium.com/svn/asterisk/trunk@176666 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-16Fix a logic error that occur when using the timerfd interfacemmichelson1-6/+14
This sequence of events posed a problem timerfd_timer_open timerfd_timer_enable_continuous timerfd_timer_set_rate timerfd_timer_disable_continuous The reason was that the timing module was written under the assumption that timerfd_timer_set_rate would not be called between enabling and disabling continuous mode. What happened in this situation was that timerfd_timer_enable_continuous saved off our previously set timer (in this situation a 0 timer, meaning it never runs out). Then timerfd_timer_disable_continuous would restore this 0 timer, even though it logically should set the timer to be whatever was set in timerfd_timer_set_rate. Now the behavior in timerfd_timer_set_rate is to overwrite the saved timer that may or may not have been set in timerfd_timer_enable_continuous. Even if timerfd_timer_enable_continuous has not been previously called, this will not harm the operation. Thanks to Terry Wilson for discovering the problem and giving me a really great debug capture that pointed out the problem clearly git-svn-id: http://svn.digium.com/svn/asterisk/trunk@168898 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25This is basically a complete rollback of r155401, as it was determined thatseanbright1-5/+5
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: http://svn.digium.com/svn/asterisk/trunk@158959 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-20Fix compilingtwilson1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@157973 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-19Cast this value since a uint64_t is not the samemmichelson1-1/+1
as an unsigned long long on a 64-bit machine. Reported by kpfleming on IRC git-svn-id: http://svn.digium.com/svn/asterisk/trunk@157874 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-19Merge the changes from the res_timing_timerfd branch.mmichelson1-0/+271
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: http://svn.digium.com/svn/asterisk/trunk@157820 f38db490-d61c-443f-a65b-d21fe96a405b