| 06:36.13 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 06:57.29 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:57.30 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:22.50 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:22.58 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:34.54 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.56) |
| 08:50.29 | *** join/#asterisk-dev pchero_work (~pchero@60.30.148.146.bc.googleusercontent.com) |
| 09:00.28 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:04.20 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 09:26.27 | *** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74) |
| 11:19.20 | *** join/#asterisk-dev tiny4783 (91ffe9f2@gateway/web/freenode/ip.145.255.233.242) |
| 11:36.53 | *** join/#asterisk-dev pchero_work (~pchero@60.30.148.146.bc.googleusercontent.com) |
| 12:41.56 | coreyfarrell | now that app_voicemail aliases are merged does it mean that gtjoseph's stasis_cache patches can go back in? |
| 12:42.34 | file | technically yes, but we're going to regroup and reevaluate |
| 12:45.18 | coreyfarrell | ack. if it's decided that the stasis_cache change cannot go into 13/16 my vote is to still push it into master (unless someone finds another solution to the caching update memory leak) |
| 12:53.01 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:57.31 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 14:39.20 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 14:41.08 | seanbright | wonders what would happen if he pinned asterisk to a single CPU and turned all lock calls into a noop |
| 14:41.34 | file | seanbright: it would not cause lunch to appear, I can tell you that |
| 15:09.18 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:09.18 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:11.30 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-jfqsxtzfflpxmkln) |
| 15:11.30 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:13.14 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-iavddtqlfiicpflu) |
| 15:13.14 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:24.38 | *** join/#asterisk-dev spditner (~simon@toroon0560w-lp140-01-69-159-37-181.dsl.bell.ca) |
| 16:04.30 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fvokwbnfyidupvvu) |
| 16:04.30 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:07.42 | coreyfarrell | seanbright: that would eventually cause corruption. a single CPU doesn't stop the kernel scheduler from preempting so you'd eventually have two threads race on a lock, read, update, write, unlock sequence. |
| 16:11.40 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 16:25.27 | seanbright | coreyfarrell: i don't think that is true |
| 16:25.39 | seanbright | but you may be right |
| 16:26.16 | seanbright | actually, i see what you mean. yes, you are right. |
| 16:26.35 | seanbright | anything that relied on mutual exclusion would fail |
| 16:52.32 | *** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74) |
| 17:13.55 | seanbright | coreyfarrell: you're a pretty smart guy, i don't care what file says |
| 17:14.22 | file | don't trust file |
| 18:13.51 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 18:26.20 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 20:25.33 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 20:53.33 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 21:08.07 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |
| 22:58.44 | *** join/#asterisk-dev _Vile (~vile@freeswitch/developer/vile) |