| 00:04.50 | coreyfarrell | rmudgett: do you think that first loader-work commit should be cherry-picked? it fixes 2 bugs but they only apply if someone tries to load a non-module or if someone dlopen's a module from outside the loader. |
| 00:05.48 | rmudgett | How could someone do that outside the loader? |
| 00:07.26 | rmudgett | Since you're still around. I thought the point of using RTLD_LAZY was to prevent unresolved symbol messages being reported while we were loading modules at the start. |
| 00:08.09 | coreyfarrell | by calling dlopen("/usr/lib/asterisk/modules/some_module.so", flags) instead of the module loader (yes a bug in of itself). |
| 00:08.41 | rmudgett | They would have to call dlopen() in their own code though. |
| 00:08.50 | coreyfarrell | yes.. |
| 00:09.31 | coreyfarrell | about RTLD_LAZY we suppress errors until the last retry. |
| 00:10.58 | rmudgett | Oh. I see. We pass a suppress flag into load_dynamic_module() |
| 00:11.10 | coreyfarrell | RTLD_NOW will cause us to report errors if a module tries using symbols that never become available. |
| 00:11.30 | coreyfarrell | in the past I guess this would be fine unless we try using the missing symbol, then I'd guess we would crash. |
| 00:12.31 | coreyfarrell | also RTLD_NOW prevents loading any modules with circular reference of globals. example a couple months ago res_pjsip used symbols from res_pjsip_session & res_pjsip_session used symbols from res_pjsip. RTLD_NOW would cause both modules to fail. |
| 00:20.55 | coreyfarrell | rmudgett: actually I think RTLD_LAZY is left-over from before the module loader had a retry loop during startup, it was so that pjsip modules could be dlopen'ed out of order. |
| 00:22.40 | coreyfarrell | the retry loop was added because RTLD_LAZY does not work when you have &symbol_from_non_loaded_module. |
| 00:23.34 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-kvkcvtaebmhsxduu) |
| 00:23.56 | rmudgett | Is that symbol from non-loaded module a function name reference? |
| 00:25.03 | rmudgett | Such as passing a function pointer to a routine when the function pointer is a function from another module and it happens to be the only reference to that external function. |
| 00:25.03 | coreyfarrell | I don't remember if it was a reference to a function or struct, gtjoseph might remember. |
| 00:25.10 | gtjoseph | what? |
| 00:25.59 | gtjoseph | do I have to look at code? cuz that's not gonna happen |
| 00:26.04 | coreyfarrell | gtjoseph: if I remember right you added the retry loop for module loader startup? |
| 00:26.10 | gtjoseph | correct |
| 00:26.22 | gtjoseph | i remember that much |
| 00:27.47 | rmudgett | That retry loop may have fixed the passing a function pointer issue I mention above. |
| 00:28.34 | gtjoseph | good |
| 00:28.34 | coreyfarrell | gtjoseph: don't worry if you don't remember |
| 00:28.42 | gtjoseph | glad i could help :) |
| 00:28.46 | coreyfarrell | rmudgett: it was 195100e770e3a6f5252be85187539149df7c6781 |
| 00:31.31 | rmudgett | The change descriptions seems to suggest it would fix the passing function pointer issue. |
| 00:35.23 | coreyfarrell | agreed. as a side effect I think it also made RTLD_LAZY unnecessary (it's apparently ignored with hardened builds anyways). |
| 00:38.09 | file | crazy baby, he doesn't understnadddddd |
| 00:40.01 | gtjoseph | RTLD_LAZY = BAD |
| 00:50.44 | file | ooo |
| 00:53.11 | gtjoseph | out of office? |
| 00:53.17 | file | no |
| 00:53.28 | gtjoseph | out of oregano? |
| 00:53.30 | file | I pushed an AOR and an endpoint into Asterisk and qualify worked |
| 00:53.48 | gtjoseph | YAY pushed via? |
| 00:53.51 | file | ARI |
| 00:53.56 | gtjoseph | Y A Y! |
| 00:54.12 | file | I should be specific, I'm adding support to my rewrite :P |
| 00:54.51 | seanbright | oh res_hep you ignorant slut... |
| 00:55.49 | file | the weekend will bring modify and delete support |
| 00:59.29 | gtjoseph | we're gonna have christmas early. |
| 01:01.18 | file | dunno 'bout that |
| 01:06.05 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0098380c9bd6e21af6.ipv6.abo.wanadoo.fr) |
| 01:20.26 | *** join/#asterisk-dev infobot (ibot@208.53.50.138) |
| 01:20.26 | *** 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 |
| 01:21.30 | seanbright | it appears that one does not |
| 01:23.42 | coreyfarrell | stasis.conf should probably be added to the list of configs that can't be overridden with extconfig.conf |
| 01:27.33 | coreyfarrell | I think declined_message_types is the only config attribute from stasis.conf that is impossible to reload. the values are only used by STASIS_MESSAGE_TYPE_INIT during startup. |
| 01:43.32 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 01:43.32 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:54.53 | coreyfarrell | rmudgett: are you looking at the 4th patch now? just asking so I don't rebase it while you have draft comments (I'm fixing the findings on patch #3). |
| 01:55.57 | rmudgett | yes. I think the first two should go to the other branches at least. The other two could as well to minimize differences. |
| 02:00.15 | coreyfarrell | ok I'll wait until I see what you find on patch #4 before I post an update. |
| 02:01.15 | rmudgett | coreyfarrell: done |
| 02:01.49 | rmudgett | leaving for the night... |
| 02:02.08 | coreyfarrell | I have a couple concerns about patches #2 and #3 for 13/15. |
| 02:02.22 | coreyfarrell | we can talk about it tomorrow, have a good night. |
| 02:05.41 | seanbright | does every bridge really need its own thread? |
| 02:08.13 | rmudgett | Bridges don't have threads. The channels in the bridges have their own threads. The softmix tech has a mixing thread. There is a global bridge manager thread to handle the odd need such as when shutting down a tech. |
| 02:11.35 | seanbright | bridge_channel_ind_thread started at [ 1874] bridge.c bridge_impart_internal() |
| 02:11.45 | seanbright | so that's the channel's thread? |
| 02:12.02 | seanbright | and if so... |
| 02:12.10 | seanbright | does every channel in a bridge really need its own thread? |
| 02:12.11 | seanbright | heh |
| 02:20.40 | seanbright | hmm, should we be breaking after setting res here: |
| 02:20.41 | seanbright | https://github.com/asterisk/asterisk/blob/master/main/rtp_engine.c#L1684 |
| 02:20.48 | coreyfarrell | if you had multiple channels with transcoding or frame/audio hooks on a single thread could that cause latency or jitter? |
| 02:21.06 | seanbright | has no idea |
| 02:22.12 | coreyfarrell | seanbright: the line you linked is not in a loop |
| 02:22.34 | seanbright | you make a great point |
| 02:22.45 | seanbright | might be time to call it a night. heh. |
| 02:22.49 | coreyfarrell | :) |
| 03:58.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00d91c3f76467d6187.ipv6.abo.wanadoo.fr) |
| 04:22.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00adaa1ae39c676c70.ipv6.abo.wanadoo.fr) |
| 06:17.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d005914c629cbec54f6.ipv6.abo.wanadoo.fr) |
| 06:32.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00395eb51a89fc9d32.ipv6.abo.wanadoo.fr) |
| 07:03.23 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:34.42 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:34.42 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:55.57 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 08:00.52 | *** join/#asterisk-dev tsearle_ (~tsearle@37.19.10.33) |
| 08:00.52 | *** mode/#asterisk-dev [+o tsearle_] by ChanServ |
| 08:23.43 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:36.02 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:43.49 | *** join/#asterisk-dev tsearle_ (~tsearle@37.19.10.33) |
| 08:43.49 | *** mode/#asterisk-dev [+o tsearle_] by ChanServ |
| 08:49.50 | *** join/#asterisk-dev tsearle__ (~tsearle@37.19.10.33) |
| 08:49.51 | *** mode/#asterisk-dev [+o tsearle__] by ChanServ |
| 09:52.31 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 09:52.32 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 14:15.43 | gtjoseph | coreyfarrell: you around? |
| 14:15.58 | coreyfarrell | yep |
| 14:16.27 | gtjoseph | Hey, can you give me some examples to test for the cli changes? I'm looking at 7558 now |
| 14:17.17 | coreyfarrell | you mean things you can do before & after checks? |
| 14:17.48 | gtjoseph | yep |
| 14:20.15 | coreyfarrell | "help acl<tab>" always worked, "help acl <tab>" did not. any aliased completion would show incorrect results if a space came before the tab (when ast_strlen_zero(n->word) is true for the generator) |
| 14:20.54 | gtjoseph | Does that apply to this view though: "CLI: Fix composite completion generators." |
| 14:21.12 | coreyfarrell | oh wow |
| 14:21.21 | coreyfarrell | need to finish my coffee |
| 14:21.29 | gtjoseph | no worries. :) |
| 14:21.49 | gtjoseph | it's my mission to get gerrit cleaned up today. :) |
| 14:21.54 | coreyfarrell | I swear I actually opened the review and just saw the wrong thing. |
| 14:22.36 | gtjoseph | take a while to let the caffeine absorb. I'm in no hurry this morning. |
| 14:23.03 | gtjoseph | it's still only 7:22 my time. |
| 14:28.59 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:28.59 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:37.35 | coreyfarrell | gtjoseph: appears I was wrong about the bug. I still want to push that commit as it simplifies code for composite generates (ie where ast_cli_completion is used with others). |
| 14:38.02 | gtjoseph | no worries. |
| 14:38.18 | coreyfarrell | that said it looks like it does fix a different bug with 'core set debug channel off <tab>" |
| 14:39.02 | coreyfarrell | sorry I mean "core set debug channel all off <tab>'.. in that case we did not return NULL from the CLI generator and we actually ran "core set debug channel all off" |
| 14:39.26 | gtjoseph | cool |
| 14:46.56 | gtjoseph | ew. i just put my pbx into a hard loop typing "core set debug channel all off P<tab>" with a PJSIP channel up. |
| 14:47.27 | file | gtjoseph: ew |
| 14:50.02 | gtjoseph | well, at least coreyfarrell fixed it. :) |
| 14:51.08 | coreyfarrell | not sure why/how that would cause a loop but glad I can help. :) |
| 14:54.18 | coreyfarrell | gtjoseph: looks like in that scenario the CLI handler would return CLI_SHOWUSAGE (AKA (void*)1), so the completion generator would see that is not NULL, add it to the list and ask for the next match. |
| 14:54.37 | gtjoseph | heh |
| 14:55.08 | coreyfarrell | so the infinite loop was actually a feature, it stopped the system from crashing |
| 14:55.50 | gtjoseph | ah. |
| 15:00.38 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-sskjnziezhjkxkbk) |
| 15:00.38 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:07.52 | coreyfarrell | gtjoseph: about the ACO regexec thing I'm tempted to just put two separate calls like I have for strcasecmp, return regexec() for whitelist, return !regexec() for blacklist. any objections to this? |
| 15:08.08 | gtjoseph | not at all. |
| 15:08.38 | coreyfarrell | the current !regexec() == !match->category_match was moved from elsewhere, I'm having trouble writing a comment explaining it so I feel like it should just be rewritten to be clearer. |
| 15:12.58 | gtjoseph | makes sense |
| 15:34.35 | seanbright | only 1042 open issues |
| 15:34.43 | seanbright | let's knock those out today too |
| 15:34.55 | gtjoseph | file will do that i'm sure. |
| 15:35.06 | file | hi |
| 15:41.01 | file | let them close, let them close, can't hold my permissions back anymoreeeeee |
| 15:41.06 | file | here I stand crafting a JQL queryyyyyy |
| 15:41.17 | file | let JIRA hate meeeeee |
| 15:41.21 | file | its errors never bothered me anyway |
| 15:46.25 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:46.25 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:57.24 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-klbtnfvyhlyvsdbf) |
| 15:57.24 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:18.26 | *** join/#asterisk-dev jfindley (~jfindley@12.239.130.226) |
| 16:25.15 | *** join/#asterisk-dev Worldexe (~Worldexe@95.107.33.134) |
| 16:48.28 | seanbright | so i ran some performance testing last night |
| 16:49.00 | seanbright | asterisk 13. i had one server set up to send calls via PJSIP to another server. that server then turned around and sent the call back to the original server. |
| 16:49.17 | seanbright | no transcoding, nothing too fancy |
| 16:49.36 | seanbright | most of the time was spent in ao2_unlock |
| 16:49.56 | seanbright | which indicates lots of contention on the channel lock |
| 16:49.58 | jsmith | seanbright: Figures... |
| 16:50.02 | seanbright | which is not too surprising |
| 16:50.16 | jsmith | Not exactly happy news, but not terribly surprising |
| 16:50.24 | file | seanbright: nope not surprising |
| 16:50.27 | seanbright | well it wasn't too bad |
| 16:51.20 | seanbright | i'm starting to think that we might benefit from creating more granular locking on ast_channels |
| 16:51.34 | seanbright | although that would be a shit ton of work |
| 16:51.41 | file | yes, yes it would |
| 16:52.04 | jsmith | I'm sure file can do that in a weekend, perhaps if we pitch in a buy snacks |
| 16:52.09 | seanbright | heh |
| 16:52.11 | file | I'm already busy |
| 16:52.48 | seanbright | file doesn't have that OPTION... if you catch my drift |
| 16:53.00 | file | the words are starting to blur together |
| 16:54.01 | jsmith | file: Understood. We could still manage to get some snacks delivered... |
| 16:55.47 | seanbright | the biggest offender was the loop in ast_waitfor_nandfds that clears the AST_FLAG_BLOCKING flag |
| 16:55.47 | coreyfarrell | seanbright: why would lock contention cause it to spend time in ao2_unlock? or did you mean ao2_lock? |
| 16:56.32 | seanbright | coreyfarrell: no, i meant unlock. the OS needs to pick a waiting thread that gets the lock next. |
| 16:56.58 | seanbright | the more threads that are waiting, the longer that takes |
| 16:57.45 | coreyfarrell | ah, I didn't know the thread releasing a lock was responsible for picking who's next. |
| 16:58.01 | seanbright | that is probably an over-simplification. but that is at least my understanding. |
| 16:58.20 | seanbright | i think the lock attributes play a role as well |
| 17:02.25 | seanbright | like PTHREAD_MUTEX_RECURSIVE is more "expensive" than PTHREAD_MUTEX_NORMAL, for example |
| 17:18.58 | coreyfarrell | I wonder how often PTHREAD_MUTEX_NORMAL would work for us.. how big of a difference is recursive vs normal? |
| 17:31.36 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:44.14 | seanbright | i honestly don't know... i'm not a pthread guy |
| 17:44.27 | seanbright | now, java synchronization i can handle. let's rewrite in java. |
| 17:49.50 | seanbright | https://pasteboard.co/GYm2jUC.png |
| 17:50.17 | seanbright | for anyone interested |
| 18:10.28 | rmudgett | Asterisk couldn't work without the recursive mutex option. |
| 18:11.11 | rmudgett | There is too much code that has a lock held and then calls a function that also grabs the same lock. |
| 18:13.22 | seanbright | some gains could be made by creating more granular locks in the ast_channel structure. but i want to audit all of the current code before i head down that path. |
| 18:14.10 | seanbright | and there are 798 calls to ast_channel_lock() in master... so that audit will take some time :-) |
| 18:14.51 | seanbright | no one add any more locking until i'm done |
| 18:14.52 | seanbright | :P |
| 18:18.03 | file | locks seanbright |
| 18:19.31 | seanbright | coreyfarrell: could you post another 10 or 15 reviews please? |
| 18:51.50 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 18:51.58 | *** join/#asterisk-dev radicaldev (~kvirc@12.239.130.226) |
| 18:53.18 | radicaldev | Anyone familiar with the mechanics of the Monitor application? I'm trying to figure out what would be involved in increasing the frequency of the writes to the audio files on disk. |
| 19:13.01 | cresl1n | radicaldev: You mean how to make it flush to disk more often? |
| 19:24.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d006d5e6ac7a0dd4388.ipv6.abo.wanadoo.fr) |
| 19:25.22 | seanbright | gtjoseph: i demand that you remove your -2 from this review |
| 19:25.22 | seanbright | https://gerrit.asterisk.org/#/c/7460/ |
| 19:25.29 | seanbright | MAKE IT SO |
| 19:25.46 | gtjoseph | maybe. can i finish my brownie first? |
| 19:25.50 | seanbright | UGH FINE |
| 19:25.51 | seanbright | heh |
| 19:26.40 | gtjoseph | stuffs the last of his brownie in his mouth and clicks 'x' |
| 19:26.50 | seanbright | splendid |
| 19:27.13 | gtjoseph | you know you don't need the #close anymore right? |
| 19:27.16 | seanbright | i do |
| 19:27.21 | seanbright | but i like it |
| 19:27.33 | seanbright | in fact, i prefer it |
| 19:27.42 | seanbright | the way it is now you can't reference an issue without closing it |
| 19:27.46 | seanbright | which is lamesies |
| 19:27.57 | gtjoseph | wait until rmudgett sees it. he's kinda pedantic about these things. :) |
| 19:28.42 | seanbright | i'm shaking in my boots |
| 19:28.55 | rmudgett | What. I like the #close too. |
| 19:29.55 | seanbright | what was the rationale behind changing it? |
| 19:30.27 | rmudgett | upgrades |
| 19:30.34 | gtjoseph | the plugin doesn't support it any more |
| 19:30.42 | gtjoseph | unfortuinately |
| 19:31.00 | file | #close originates from JIRA smart tags, which were extremely unreliable |
| 19:31.10 | file | smart commit tags rather |
| 19:31.27 | seanbright | ah |
| 19:31.44 | file | the current mechanism is purely a Gerrit plugin that reacts to events that occur to reviews, but it does not have tags to do things |
| 19:32.09 | file | it's simplified to that degree but works always, unless the issue is in the wrong state and it can't transition |
| 19:32.28 | seanbright | well, i have to say, we have a room full of smart people |
| 19:32.43 | seanbright | this should be the highest priority |
| 19:32.46 | radicaldev | cresl1n: Precisely! |
| 19:34.37 | radicaldev | cresl1n: At present it flushes a fairly large chunk every second or so, I'm looking for more frequent flushes of smaller chunks for a real-time streaming application. |
| 19:34.51 | radicaldev | "real-time" that is |
| 19:35.19 | cresl1n | You'll probably need to modify the source code for that |
| 19:37.13 | radicaldev | Yeah I know, Just wondering if anyone is familiar with that application that could point me in the right direction. Seems like the Monitor application may have been a bit of a hackjob with references all over the place. |
| 19:37.25 | cresl1n | It's old |
| 19:40.10 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 19:40.10 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 19:41.05 | cresl1n | I think it might depend on the format in question |
| 19:41.22 | cresl1n | What file format are you writing? |
| 19:41.48 | radicaldev | Looking for the default output which is wav, s16le at 8k sampling rate |
| 19:42.35 | cresl1n | Ok |
| 19:42.48 | cresl1n | that's probalby format_wav.c |
| 19:44.26 | cresl1n | It uses the FILE stream API |
| 19:45.21 | cresl1n | in the wav_write function, you might add an fflush() on the file stream before it returns |
| 19:45.40 | cresl1n | hopefully that would flush out any data in the buffers to the operating system |
| 19:45.54 | cresl1n | not a great idea from a performance perspective though |
| 19:58.25 | radicaldev | cresl1n: Heh, probably not. I'll see what I can do. Thanks for the tip! |
| 20:21.15 | rmudgett | gtjoseph: Does openSSL even have a sane version scheme? |
| 20:21.23 | gtjoseph | yep |
| 20:21.26 | gtjoseph | well defined |
| 20:21.37 | gtjoseph | https://wiki.openssl.org/index.php/Manual:OPENSSL_VERSION_NUMBER(3) |
| 20:31.31 | cresl1n | well defined != sane |
| 20:31.33 | cresl1n | :-P |
| 20:39.46 | coreyfarrell | seanbright: nah, I think I'm done for now. also rmudgett gets some credit for my flood of reviews today, I hadn't planned on cherry-picking the loader-work patches. |
| 20:40.59 | gtjoseph | i'll be going over them over the weekend to get them pushed through. |
| 20:42.03 | coreyfarrell | rmudgett: about non-recursive mutex I wasn't talking across the board.. more wondering if any specific places could use them and have a performance benefit from it. |
| 20:44.20 | rmudgett | Well, the channel lock is the 800lb gorilla and it depends upon recursive mutexes. :) |
| 21:03.39 | cresl1n | I wish we didn't have recursive mutexes |
| 21:04.23 | cresl1n | It seems like cheating when you have to enable them |
| 21:05.54 | file | cresl1n: go back in time... |
| 21:07.43 | seanbright | but they aren't required, they just make things easier |
| 21:07.49 | seanbright | "easier" |
| 21:16.20 | cresl1n | they went in a long time ago |
| 21:16.34 | cresl1n | so long ago they'd be hard to remove |
| 21:19.45 | file | they predate me |
| 21:19.52 | file | but do they predate cresl1n? |
| 21:19.57 | cresl1n | no |
| 21:20.06 | cresl1n | I remember when Mark stuck them in |
| 21:27.58 | seanbright | i don't think removing them is feasible, but having more granular locking on the channel structure could help in some situations. but that is just a guess. |
| 21:30.22 | coreyfarrell | I doubt we can ever remove recursive mutex but we could create an ast_mutex_init_nonrecursive. obviously ast_channel_lock wouldn't be able to use it but I'm sure other locks could. |
| 21:30.58 | seanbright | but that's based on the assumption that recursive mutexes are "bad" |
| 21:31.51 | coreyfarrell | I thought you said it was more expensive? |
| 21:32.03 | seanbright | i assume it is, but i haven't measured it |
| 21:32.13 | seanbright | what appears to be expensive from my profiling is lock contention |
| 21:32.32 | seanbright | and the lock in question happens to be recursive |
| 21:34.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00acf6dd52ed8db987.ipv6.abo.wanadoo.fr) |
| 21:36.24 | seanbright | so here's a thought |
| 21:37.21 | seanbright | change ast_channel.flags to use __sync_or_and_fetch and __sync_nand_and_fetch |
| 21:37.41 | seanbright | and then don't lock around them |
| 21:39.18 | seanbright | or the newer __atomic_* versions |
| 21:42.48 | seanbright | i have no clue what i am talking about, carry on |
| 21:43.49 | coreyfarrell | seanbright: it sounds like a reasonable idea. see asterisk/lock.h we have the ast_atomic_* functions. the only issue is how you would deal with systems which don't support atomics (like ast_atomic_fetchadd_int_slow) |
| 21:44.38 | seanbright | fuck 'em? |
| 21:44.54 | seanbright | is that an option? |
| 21:45.19 | coreyfarrell | I think it should be. |
| 21:45.45 | seanbright | and that is why we don't run the project :-) |
| 21:46.01 | file | hehe |
| 21:46.07 | coreyfarrell | if your idea had a benefit to performance then why should the primary target be penalized for some obscure system. |
| 21:46.27 | file | depends on the result |
| 21:46.31 | seanbright | right |
| 21:47.41 | seanbright | the "slow" variants of any of the atomics would either need to be CAS (which is problematic for the purposes of flag setting), or you'd need to wrap it in a lock |
| 21:48.24 | coreyfarrell | CAS? |
| 21:48.53 | seanbright | here's my opinion and what i will be moving forward with: the coarse channel locking we have today _may_ be improved by creating more fine grained locks that are responsible for smaller chunks of the channel structure |
| 21:48.57 | seanbright | compare and set |
| 21:49.40 | seanbright | before ao2 we needed to lock the whole damn thing to make sure it didn't go away |
| 21:49.47 | seanbright | now we don't have to do that |
| 21:49.52 | seanbright | so it opens up some options |
| 21:49.52 | file | aye |
| 21:50.06 | seanbright | so i'll shut up and start experimenting :-) |
| 21:51.00 | coreyfarrell | seanbright: if someone has the slow variants then performance is already bad - if they don't have real atomics then ao2_ref uses a global lock. so I don't think it would be a problem if flags did worked the same way. |
| 21:51.19 | seanbright | flags were just an example, but i agree |
| 21:52.47 | seanbright | BUT... i finally go around to opening up this raspberry pi that i got at astricon and now i want to compile asterisk on an arm processor |
| 21:52.59 | seanbright | i'm told it should take about 8 hours |
| 21:53.02 | seanbright | heh |
| 21:53.27 | coreyfarrell | at some point I'll look into having ./configure throw a warning or maybe even an error if fast atomics aren't available (obviously master only). add an option --enable-slow-atomics to bypass the error. |
| 21:56.44 | coreyfarrell | seanbright: if you are running fedora on the pi you can use fedoraproject's build infrastructure to build an RPM for you (assuming you don't include anything against fedora rules). |
| 21:57.19 | seanbright | i had planned to put ubuntu on it |
| 21:57.34 | seanbright | but i'm missing an hdmi cable at the moment so i'm dead in the water |
| 21:57.59 | file | how can you not have an HDMI cable? |
| 21:58.01 | coreyfarrell | I used fedora infrastructure to build node.js 8.0.0 for my raspberry pi (it failed to build locally because the linker ran out of ram after like 8 hours) |
| 21:58.09 | seanbright | all of my monitors are displayport |
| 21:58.17 | coreyfarrell | asterisk won't be a problem though |
| 21:58.34 | seanbright | and i'm at the office. i'm sure i have one at home. |
| 22:04.26 | seanbright | coreyfarrell: based on the number of commits you have in the last few months, i'm going to have to ask you not to come to next year's astricon |
| 22:04.34 | seanbright | heh |
| 22:04.54 | coreyfarrell | why's that? |
| 22:05.03 | seanbright | because you will be higher than me in number of commits |
| 22:05.07 | seanbright | and i can't have that |
| 22:05.28 | seanbright | used to be funny. |
| 22:05.35 | cresl1n | Ha! |
| 22:05.39 | coreyfarrell | so I guess you better get to work :P |
| 22:06.07 | seanbright | pfft |
| 22:06.08 | seanbright | "work" |
| 22:06.08 | file | gives seanbright a ferrero rocher |
| 22:06.15 | cresl1n | eats it |
| 22:06.27 | file | cresl1n: thief |
| 22:06.28 | seanbright | sounds italian |
| 22:06.32 | cresl1n | I'm super hungry |
| 22:06.35 | coreyfarrell | who would deal with a user having trouble signing into jira? I got https://pastebin.com/rfMUGZZR by email from the reporter. |
| 22:07.52 | cresl1n | that's odd |
| 22:08.02 | cresl1n | what type of trouble is he having? |
| 22:08.22 | file | it's also on the login page on the left hand side, For problems with the Asterisk issue tracker, please email asteriskteam@digium.com |
| 22:08.24 | seanbright | cresl1n: it's obvious from his message |
| 22:08.30 | coreyfarrell | I pastebin'ed the entire email I received. |
| 22:08.32 | seanbright | "I can't seem to login" |
| 22:08.35 | seanbright | duh |
| 22:09.04 | coreyfarrell | well the entire email body.. |
| 22:09.07 | cresl1n | ok |
| 22:09.29 | cresl1n | Yeah, asteriskteam@digium.com is a good place to start |
| 22:09.43 | cresl1n | goes to check that filter to see if he missed something |
| 22:10.13 | file | his account itself is fine though |
| 22:10.32 | cresl1n | Man, I've got so much other crap that goes to that filter too |
| 22:10.47 | coreyfarrell | for the record on #1, I'm not the first to say on that ticket that we didn't really want CLI concise commands. rmudgett said so nearly 2 years ago but was ignored. |
| 22:11.32 | cresl1n | I need food. |
| 22:11.59 | cresl1n | stupid smoothie didn't cut it for lunch |
| 22:20.19 | rmudgett | I find it amusing that after nearly two years he still hasn't understood my comments. :) |
| 22:29.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0025f27c9ecc073d38.ipv6.abo.wanadoo.fr) |
| 23:33.50 | coreyfarrell | rmudgett: wow I guess I really messed up that CLI patch. for chan_sip / chan_skinny I'm thinking of breaking them off to a separate patch. for those two channel drivers I think I should switch all the CLI_GENERATOR's in each source at once. |
| 23:45.38 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d009899f84320c96665.ipv6.abo.wanadoo.fr) |
