| 00:21.11 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:21.11 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 05:12.52 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-250-191.dhcp.nwtn.ct.charter.com) |
| 05:12.52 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 05:36.34 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.162) |
| 06:20.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:43.59 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:43.59 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:25.15 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 07:51.35 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:54.34 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 08:05.47 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:02.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:852e:3b59:c628:7dc0) |
| 10:35.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 11:33.40 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:49.19 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 14:00.33 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zwvnkbexigppsldr) |
| 14:00.33 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:28.30 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-gscgjgtkwjllzbhq) |
| 14:28.30 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:45.10 | kharwell | gtjoseph: there was an open question on file's review you just pushed in. I guess I should have given it a -1 earlier so it would have been more noticeable. |
| 14:45.23 | gtjoseph | uhm yeah. |
| 14:45.37 | file | the one I answered? or did Gerrit forget it |
| 14:45.39 | gtjoseph | a -1 after a +2 doesn't do much :) |
| 14:45.42 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ltnhavzqmfevviwa) |
| 14:45.42 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:45.58 | gtjoseph | he didn't -1 until after I +2'd |
| 14:46.02 | file | the heck, Gerrit forgot it |
| 14:46.42 | kharwell | The question was there before the merge. I -1 to try to stop it, but yeah the +2 overrides it once it's on it's way |
| 14:46.44 | file | kharwell: to answer your question - the remote address isn't known then, and the test itself only cares about what port Asterisk has in use, if that changes in the future then it can be revisited |
| 14:47.31 | kharwell | ya you answered that part. I had followed up with should we move it now or would it be worthwhile, but no biggie. Yeah we can address later if needed |
| 14:48.12 | file | it's not worthwhile, no jumping of the gun or preoptimization before we need things dang nabbit! |
| 14:49.37 | kharwell | for some things yes |
| 14:57.35 | pc-m | hello everyone, I'm currently building an application using ARI and I noticed a behavior when using /channels/id/hold. Given Alice and Bob are both in a mixing bridge. When I put Alice on hold using POST /channels/{channelId}/hold. Then Alice hears the default moh but Bob can still hear Alice. Is this a bug or is it by design? At the moment I use /hold followed by /mute to do what I want but I was wondering if I should open a bug |
| 14:57.35 | pc-m | nd fix that problem. |
| 14:59.15 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 14:59.26 | file | neither probably, it just wasn't considered most likely |
| 15:10.13 | pc-m | would it be acceptable if I changed /channels/{channelId}/hold to also stop the sound from the channel? at the moment /hold does the same as /moh without the option to choose the mohClass |
| 15:12.03 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:12.03 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:16.29 | file | coreyfarrell: psst |
| 15:30.36 | file | pc-m: probably... |
| 15:49.53 | seanbright | did anyone actually test the odbc change that was just merged or did we just rubber stamp it? |
| 15:53.37 | file | I'm a crappy dev, I didn't test it :( 10 demerits to me |
| 15:55.09 | seanbright | good times |
| 15:55.18 | file | it didn't merge in |
| 15:55.28 | seanbright | ah, right |
| 15:56.34 | gtjoseph | it didn't merge for unrelated reasons. do we not want it to merge? |
| 15:56.51 | seanbright | i will take care of it |
| 15:57.01 | gtjoseph | kk |
| 15:57.51 | seanbright | slackware... SERIOUSLY?! |
| 15:58.16 | seanbright | https://www.livememe.com/ohzrd5t |
| 15:58.52 | file | ahahahahaha |
| 15:58.53 | file | "Access to this page has been blocked due to inappropriate content." |
| 15:59.22 | seanbright | it's the "what year is it" meme |
| 15:59.58 | file | cute |
| 16:07.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d002ccf8e8efcb548cb.ipv6.abo.wanadoo.fr) |
| 17:27.54 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ahaahjopujwjvrgn) |
| 18:09.38 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dfvjsofbpisexvag) |
| 18:09.38 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 19:20.58 | coreyfarrell | file: yes? |
| 19:21.43 | file | coreyfarrell: a few users trying out Asterisk 16 have encountered struggles as a result of the module loader change - specifically optional modules like I mentioned yesterday, getting confused over how to resolve what wasn't previously a problem |
| 19:22.13 | file | coreyfarrell: I looked at the CHANGES and UPGRADE docs and didn't see any mention of it - I think before the 16 release there probably needs to be something there |
| 19:22.50 | file | it's probably good if we had a wiki page too talking about it a bit |
| 19:22.51 | file | thoughts? |
| 19:23.15 | coreyfarrell | groan's (but agrees) |
| 19:24.36 | rmudgett | agrees to documentation only for that. :D |
| 19:26.48 | jameswf | rtfc.... the code is documentation... this is open source |
| 19:31.13 | coreyfarrell | file: do you have any specifics about the issue users were running into so I can test the logger output? I think having appropriate LOG_ERROR is probably the most important way this should be documented (it's the only thing most users who experience an issue will ever read). |
| 19:31.23 | file | the one I know of was statsd.conf missing |
| 19:31.26 | file | rippling up to PJSIP |
| 19:32.15 | file | res_smdi was another |
| 19:35.48 | coreyfarrell | thanks deleting statsd.conf will be easy to test. |
| 19:37.26 | gtjoseph | the problem with log_error is that startup messages is that you don't want to scramble to figure out what's going on when asterisk doesn't start or do something you were expectingf it to do. |
| 19:40.10 | gtjoseph | res_smdi was the one that bit me when testing app_voicoemail |
| 19:43.47 | coreyfarrell | gtjoseph: I wasn't suggesting that the logger message should be in place of CHANGES / UPGRADE / wiki docs, just that won't people won't check anything before testing the upgrade so the logger message should be good. |
| 19:44.03 | file | as much as can be done |
| 19:44.39 | gtjoseph | ok |
| 19:47.45 | coreyfarrell | gtjoseph: I think the 16+ behavior is correct, modules which use optional_api modules *should* be prevented from starting ig the optional_api module dlopen's but fails to start. unless someone wants to untangle optional_api.c so it is integrated with module startup: don't replace stubs until the optional_api module starts, manage module references based on exposing implementation functions. |
| 19:47.58 | jameswf | There is no real way to get dependencies I am guessing |
| 19:48.10 | jameswf | so you know touch foo.conf |
| 19:48.12 | gtjoseph | tldr; :) |
| 20:01.18 | seanbright | https://github.com/asterisk/asterisk/blob/13/utils/extconf.c#L77-L78 |
| 20:01.26 | seanbright | just a typo you think>? |
| 20:02.28 | seanbright | ASINCLUDE_GLOB doesn't appear anywhere else in the source |
| 20:03.05 | file | maybe? |
| 20:04.07 | seanbright | that code is 11 years old... |
| 20:06.10 | coreyfarrell | file / gtjoseph / rmudgett: should I add a flag to the internal module structure to avoid automatic retries of res_statsd:load_module() once it returns AST_MODULE_LOAD_DECLINE? |
| 20:07.22 | coreyfarrell | also I'll update the logger message "Failed to load %s due to unfilled dependencies." to list what is missing. |
| 20:08.46 | rmudgett | coreyfarrell: I thought it already had something like that when a module declined. |
| 20:10.29 | coreyfarrell | hmmm I'll check that.. maybe the dependency resolver is just failing to consider that. |
| 20:11.19 | seanbright | i would like to propose removing conf2ael |
| 20:11.48 | rmudgett | seanbright: I would like to propose removing AEL and LUA support. |
| 20:11.54 | seanbright | i use ael |
| 20:11.55 | seanbright | so no |
| 20:11.57 | seanbright | BUT |
| 20:11.58 | seanbright | https://github.com/asterisk/asterisk/blob/13/utils/conf2ael.c#L342-L349 |
| 20:12.13 | seanbright | 11 years old |
| 20:13.38 | coreyfarrell | seanbright: we did deprecate a few utils/ in 16+ (including conf2ael) |
| 20:13.44 | seanbright | ok cool |
| 20:14.16 | rmudgett | Besides that note you pointed out is still correct. It is still a preliminary version still going through trials. :) |
| 20:16.09 | seanbright | /* TODO: We need to fix this next - SRB 2007/11/19 */ |
| 20:16.33 | file | legacy code is a fun place |
| 20:21.15 | *** join/#asterisk-dev fblackburn (~fblackbur@qubcpq0957w-lp140-01-76-64-186-214.dsl.bell.ca) |
| 21:38.57 | coreyfarrell | rmudgett: for the astobj2 review I assume no action needed for the 'FYI' comments? I was aware that the improvement is from removal of padding, part due to forcing options & magic into 32-bit total. |
| 21:39.18 | rmudgett | correct |
| 21:40.25 | coreyfarrell | also I was thinking that if we do need to add another bit to the options we can just reduce the 'magic' further. I mean the 29-bit check has a 2 in a billion chance of randomly matching (2 matching values out of 1 billion possible values). |
| 21:41.33 | seanbright | couple questions about that |
| 21:41.44 | seanbright | is there a use-case for a negative refcount? |
| 21:41.56 | rmudgett | As long as the magic number isn't likely to be matched. zero and all ones are not good magic numbers |
| 21:42.07 | seanbright | and is there a reasonable upper bound for refcount that is not 2^31? |
| 21:43.01 | coreyfarrell | upper bound is 100,000 (we have a check for that which asserts). we use signed int because 'ao2_ref(obj, -2)' is done in a couple places, so we assert if it goes negative. |
| 21:43.11 | seanbright | got it |
| 21:43.16 | rmudgett | seanbright: We have occasionally hit very high ref counts. One system did hit a ref count over the int size. Wasn't able to find the reason why that happened. :) |
| 21:43.51 | rmudgett | That is why the excessive ref count FRACK is not optionally compiled in. :D |
| 21:44.39 | rmudgett | People have actually reported that FRACK unfortunately. :( |
| 21:45.20 | seanbright | what about not compiling in the magic number? |
| 21:45.26 | coreyfarrell | also the refcount field has to be compatible with atomic operations.. we can't use 'int ref_count:21' because you can't take the address of that. int16_t would definitely be too small. |
| 21:45.42 | seanbright | unless AO2_DEBUG is defined |
| 21:46.02 | coreyfarrell | not using the magic number would allow us to skip that check but on most platforms I don't think that would save memory (the struct would just get padded) |
| 21:46.48 | rmudgett | The magic number check is a very good sanity check. It has failed often enough. |
| 21:48.09 | rmudgett | coreyfarrell: The ao2 patch should get a minor performance boost due to memory caching |
| 21:48.17 | seanbright | seems like an assert would be sufficient |
| 21:48.26 | seanbright | but if it doesn't save space, it's not relevant |
| 21:48.52 | coreyfarrell | rmudgett: what do you mean? the current patch will improve caching? |
| 21:49.24 | rmudgett | We do a magic number check before the ref count is modified by ao2_ref |
| 21:49.49 | rmudgett | That should pull the memory into the cache |
| 21:50.33 | rmudgett | before the ref count was 32+ bytes away from the magic number |
| 21:50.50 | rmudgett | unless cache lines are much larger these days |
| 21:51.50 | rmudgett | not sure if the caching will offset working with bitfields though |
| 21:54.19 | coreyfarrell | I would think the bitfield should be cheap since they're immutable and we only check magic against a static value? |
| 21:54.43 | rmudgett | extracting bitfields could be expensive |
| 21:55.01 | rmudgett | though on x86 processors maybe not that expensive |
| 21:55.54 | rmudgett | with 8051 processors it was: Absolutely avoid |
| 21:56.53 | seanbright | that's like 40 year old technology |
| 21:57.10 | seanbright | but so am i, so... pfft |
| 22:04.37 | jameswf | Raspi? |
| 22:04.44 | jameswf | those peeps |
| 22:12.59 | coreyfarrell | rmudgett: I just remembered ast_atomic_fetch_add is only in 16+ so the patch cannot be cherry-picked to 13/15 without either backporting a function for 'int32_t' or continuing to use 'int ref_counter' for those versions. |
| 22:15.03 | rmudgett | is an int 8 bytes on your platforms? |
| 22:16.06 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-dfvjsofbpisexvag) |
| 22:19.05 | coreyfarrell | rmudgett: hmm no it's 32-bit on my system, but it doesn't have to be. apparently the specs only require that it be at least 16-bit. so apparently int -> int32_t doesn't change anything on x86_64. |
| 22:20.09 | rmudgett | I think Asterisk depends upon int being at least 32 bits |
| 22:20.39 | rmudgett | We certainly have enums that have 32 bits used |
| 22:20.51 | rmudgett | In some cases we need more bits too. :) |
| 22:22.45 | rmudgett | Is it possible to backport the ast_atomic_fetch_add routines? |
| 22:22.59 | coreyfarrell | maybe keeping 13/15 on 'int ref_counter' but doing the re-order and bitfield would be best? the specs don't forbid 'int' from being 64-bit. I still like making the fields fixed width on 16+ (since we have the required atomic macro). |
| 22:23.30 | rmudgett | make sense to me |
| 22:24.18 | coreyfarrell | rmudgett: I don't think so, I think we would have to create a ast_atomic_fetchadd_int32 function because 13/15 support systems without __sync / __atomic built-ins. |
| 22:24.37 | rmudgett | ok |
| 22:25.31 | coreyfarrell | since I don't know any any platform where int -> int32_t matters I'm don't feel like bothering with ast_atomic_fetchadd_int32. if someone has a platform where it matters they can deal with it. |
| 22:25.43 | coreyfarrell | or upgrade to 16+ |
| 22:30.49 | coreyfarrell | rmudgett: about the lock stuff, do you have any guesses on how often locking is done through ao2 vs direct use of lock.h ast_mutex_t / ast_rwlock_t? |
| 22:33.18 | rmudgett | I don't know. I think direct locking is getting less used though. |
| 22:33.54 | rmudgett | Cannot get very far in Asterisk code without running into ao2 usage. :) |
| 22:34.57 | rmudgett | For DEBUG_THREADS though it doesn't matter if direct locking or through ao2. |
| 22:36.24 | rmudgett | DEBUG_THREADS almost has no API changes when enabled or disabled. It is mostly in the deadlock avoidance macros. |
| 22:38.07 | rmudgett | which is nice. |
| 22:38.31 | rmudgett | and also better than I originally thought |
| 22:39.31 | coreyfarrell | I'm considering if it would be worth it to have astobj2.c use pthread_mutex_t / pthread_rwlock_t directly, make it call lock.c tracking functions if DEBUG_THREADS is enabled. bringing that into the private ao2 implementation would let us make the tracking field conditional and avoid the initialization issues entirely. |
| 22:40.32 | coreyfarrell | the reason ast_get_reentrancy needs the global mutex is because the tracking field can be uninitialized. |
| 22:42.13 | coreyfarrell | so having astobj2.c use pthread locking directly would improve performance when DEBUG_THREADS is enabled and reduce memory usage when it's disabled. |
| 22:45.36 | rmudgett | When DEBUG_THREADS is enabled we need to allocate tracking memory when the lock is first locked. We don't want that overhead until and unless the lock is first locked. The lock may never be used. |
| 22:48.12 | rmudgett | It wouldn't really improve performance if DEBUG_THREADS is disabled since most of __ast_pthread_mutex_lock() is conditionaled out. |
| 22:50.40 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 22:50.40 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 22:53.15 | coreyfarrell | rmudgett: having astobj2.c call upon tracking directly would make the tracking field private, so the field could be in '#ifdef DEBUG_THREADS', it would save 16 bytes per ao2 (on x86_64). |
| 22:55.20 | rmudgett | hmm. That wouldn't make it faster. Just save memory. |
| 22:57.00 | coreyfarrell | hmm actually we could just add a '#if defined(DEBUG_THREADS) || !defined(DEBUG_THREADS_LOOSE_ABI)' to the lock.h, then astobj2.c would '#define DEBUG_THREADS_LOOSE_ABI'. this way the lock.h structs defined in astobj2.c would be truncated when DEBUG_THREADS is not enabled. |
| 22:59.25 | coreyfarrell | I will work on adding the double-check flag as you suggested to improve performance, then I'll do a followup to make it so astobj2.c can reduce lock related memory. |
| 23:00.26 | rmudgett | Beware of ao2_object_get_lockaddr(). Probably not really since when DEBUG_THREADS is disabled, the extra fields wouldn't be used. |
| 23:03.45 | coreyfarrell | ack. so if I do that then probably need a doxygen comment that memcpy cannot be used on the result of that function. |
| 23:04.43 | coreyfarrell | I'm not sure it's even valid to memcpy pthread mutex/rwlock anyways. |
| 23:27.11 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 23:27.11 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 23:31.38 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 23:32.11 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 23:32.11 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 23:48.41 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 23:48.41 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |