asterisk

Commit Graph

Author	SHA1	Message	Date
Russell Bryant	74fada439f	Merged revisions 163241 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r163241 \| russell \| 2008-12-11 15:21:31 -0600 (Thu, 11 Dec 2008) \| 8 lines 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/branches/1.6.1@163252 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	6ed6a5ae29	Merged revisions 140489 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r140489 \| mmichelson \| 2008-08-29 12:47:17 -0500 (Fri, 29 Aug 2008) \| 30 lines 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/branches/1.6.1@140490 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

8 Commits (f55f994661d4b4a08b58a0df01b693acc33bfec2)