| 02:42.29 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-zowixuafttjqjmtb) |
| 03:26.58 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 03:26.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 03:52.56 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 04:03.44 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 04:52.10 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:34.52 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 05:34.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:44.11 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 07:03.24 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:20.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:20.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:58.03 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-dycjzmrbvbzqvepr) |
| 11:16.43 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 11:34.01 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:34.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:34.32 | *** join/#asterisk-dev acidfoo_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 11:37.24 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 12:20.25 | *** join/#asterisk-dev [TK]D-Fender (~Joe@216-191-106-165.dedicated.allstream.net) |
| 13:39.28 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26) |
| 13:41.28 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:41.28 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:50.08 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:53.45 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-jrdrmnyrgxwxdnrb) |
| 14:03.24 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-zgweuhpkskcdavex) |
| 14:03.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:28.54 | gtjoseph | file: i think the same guy that was on your flight with the headphones not quite plugged in was on my flight last night. :) |
| 14:29.13 | file | did the flight attendant make them aware? |
| 14:29.27 | gtjoseph | a fellow passenger took care of it. |
| 14:29.33 | file | :D |
| 14:30.43 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-sgimgpqpkmnvdqvr) |
| 14:30.43 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:32.13 | gtjoseph | what happened with the regcontext? Did i reorder the continuation lines or something? |
| 14:32.45 | file | the fields were swapped for two options |
| 14:33.32 | gtjoseph | yeah i must have done that when trying to make sense of the merge conflict |
| 14:34.06 | gtjoseph | and i see i've got another to fix |
| 14:34.39 | file | yeah, it wouldn't rebase from gerrit so I left it |
| 14:34.53 | gtjoseph | i'll grab them in a few monites |
| 14:34.55 | gtjoseph | minutes |
| 14:44.28 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-azrmkybjtlvfujoh) |
| 15:54.03 | *** join/#asterisk-dev acidfoo_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 16:35.31 | *** join/#asterisk-dev Navion (~Navion@rivendell/users/navion) |
| 16:45.41 | *** join/#asterisk-dev bof22 (~Thunderbi@80.12.39.186) |
| 17:02.10 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:02.10 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:11.04 | gtjoseph | file: how about if I make the link into the unidentified_requests container contingent upon auth_username being in the endpoint_identifier_order list? That should eliminate the attack vector. |
| 17:11.24 | gtjoseph | at least for those who don't need the capability |
| 17:11.51 | file | yes |
| 17:13.20 | *** join/#asterisk-dev lnxslck (~lnxslck@av3-84-90-162-98.netvisao.pt) |
| 17:31.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 17:31.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:36.49 | file | I'll take second eyes on PBX hints |
| 17:38.52 | file | and my race condition fix, cause why not |
| 18:30.32 | gtjoseph | file: on the race in registrar_expire... If the serialized scheduler (2486) goes in, this thread will go away. |
| 18:31.32 | file | aye |
| 18:31.39 | file | I live in the now, not the then :D |
| 18:33.13 | gtjoseph | :) |
| 18:37.15 | gtjoseph | well, this sucks... when you edit a commit message you lose your +1s. didn't used to do that i don't think. |
| 18:37.20 | file | it did. |
| 18:37.24 | gtjoseph | gerrit that is. |
| 18:37.25 | file | it's an entirely new commit |
| 18:37.35 | gtjoseph | hmmm. |
| 18:38.18 | gtjoseph | ah well, i guess i should have left that typo for rmudgett to find. |
| 18:39.23 | rmudgett | Na. I don't fin em all. My spling not that good |
| 18:39.34 | rmudgett | :) |
| 18:46.00 | rmudgett | gtjoseph: Objects retrieved from sorcery are created without locks. |
| 18:46.13 | rmudgett | This is because they are supposed to be immutable |
| 18:53.02 | acidfoo_ | speaking of SIP cache expiry, does any one know from the top of his head what variable control when a cache entry get expired ? (I'm digging and I'lll continue my research, but if anyone had some pointer, I'd be happy to take them :) |
| 18:53.13 | gtjoseph | well, even if they did have locks, they wouldn't work |
| 18:53.24 | file | acidfoo_, you'll have to be specific... there's two SIP stacks now... |
| 18:53.35 | acidfoo_ | the old one |
| 18:53.45 | acidfoo_ | in chan_sip ;) |
| 18:53.50 | acidfoo_ | sorry |
| 18:55.00 | file | gtjoseph, it'll check eventually... it's also gating |
| 18:56.09 | gtjoseph | ah gotcha |
| 19:13.03 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-zjyivgghzjsgkkox) |
| 19:13.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:21.45 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 19:52.44 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-tknkyqdgxkvkkolm) |
| 19:52.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:33.17 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:39.08 | *** join/#asterisk-dev acidfoo_ (~acidfoo@69-165-160-113.dsl.teksavvy.com) |
| 21:49.21 | gtjoseph | rmudgett: not understanding the " you will be creating and destroying the named lock for every attempt" comment. if a trylock fails, someole else has a ref to the lock so there's no create/destroy. |
| 21:49.31 | gtjoseph | s/someole/someone/ |
| 21:50.39 | gtjoseph | the get/put is also a little harder to use than the single operation. |
| 21:50.45 | gtjoseph | what did I miss? |
| 21:52.09 | file | the destruction of the previous universe |
| 21:52.31 | gtjoseph | hey, out with the old and in with the new. :) |
| 21:53.53 | rmudgett | Hm. The trylock isn't as bad as I originally thought because for trylock to fail someone else has to have the lock. |
| 21:54.03 | gtjoseph | exactly |
| 21:54.27 | gtjoseph | the path length is the same either way |
| 21:54.34 | rmudgett | However, you can get some thrashing of the named_lock object because the lock could be released before the named trylock returns |
| 21:55.34 | gtjoseph | hmmm |
| 21:56.10 | rmudgett | For trylock you are likely to put it into a loop |
| 21:56.59 | gtjoseph | not seeing it |
| 21:57.07 | rmudgett | As for the get/put it separates the create/lock and unlock/destroy operations |
| 21:57.37 | gtjoseph | yeah it does but to what benefit? |
| 21:58.07 | rmudgett | You don't need to have special lock/trylock/unlock functions. |
| 21:58.18 | rmudgett | You only need the get/put operations |
| 21:58.48 | gtjoseph | true but it's an extra step everyone then has to do |
| 21:59.13 | gtjoseph | back to the trylock though... |
| 21:59.14 | rmudgett | It separates the concerns so you can tell the difference between a failure to create and a failure to acquire the lock |
| 21:59.51 | gtjoseph | ok, it's easy enough to separate. |
| 22:00.28 | rmudgett | For the create destroy thrashing. Someone else has the lock. You trylock and it fails. While you are exiting the trylock function, the other thread releases the lock. Now when you exit, the lock is destroyed. |
| 22:00.59 | gtjoseph | and your next attempt creates it. |
| 22:01.49 | rmudgett | True but it was needlessly destroyed because you are going to trylock again |
| 22:02.22 | rmudgett | If there is much contention then there will be a bit of thrashing |
| 22:02.29 | rmudgett | going on |
| 22:02.31 | gtjoseph | true but it won't loop |
| 22:03.13 | gtjoseph | the only way to prevent that is to let the object hang sround a while |
| 22:03.35 | gtjoseph | but that implies some housekeeping to expire them |
| 22:04.04 | rmudgett | Which that is accomplished by separating the create/destroy concern from the lock/unlock |
| 22:04.48 | gtjoseph | Oh, now i see what you're saying. |
| 22:05.20 | rmudgett | Also what happens if a routine wants to lock/unlock several times |
| 22:05.47 | rmudgett | If it is the only one locking then the lock is created destroyed several times. |
| 22:06.01 | gtjoseph | yeah, true. ok. can't use SCOPED_LOCK any more though |
| 22:06.40 | rmudgett | I've not been a fan of SCOPED_LOCK because it is a RAII_VAR in disguise :) |
| 22:06.52 | gtjoseph | :) |
| 23:43.20 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 23:43.20 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:43.42 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-jrdrmnyrgxwxdnrb) |
| 23:51.33 | *** join/#asterisk-dev acidfoo_ (~acidfoo@69-165-160-113.dsl.teksavvy.com) |