asterisk

Commit Graph

Author	SHA1	Message	Date
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	18 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	18 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	18 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	18 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	18 years ago

11 Commits (665bba38f13c38f27daade9c7a48f035c13d3fee)