| 00:12.07 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 00:41.15 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 00:48.36 | codefreeze | jsmith-away: I'm back... so, find anything out? |
| 00:53.26 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:53.26 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:54.44 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 01:18.14 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 01:18.14 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 01:31.51 | *** join/#asterisk-dev ratdesang (i=cramey@78-160-237-24.mvl.swc.static.gci.net) |
| 01:42.15 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 02:03.20 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 03:33.49 | codefreeze | drumkilla: during the week he's "russellb", but on weekends, it's wild and crazy "drumkilla"! |
| 03:34.06 | drumkilla | lol |
| 03:34.09 | drumkilla | that's right! |
| 03:34.36 | Corydon76-dig | drumkilla, with the killer drumsticks |
| 03:35.08 | drumkilla | i do have some killer drumsticks in my office. |
| 03:35.16 | Corydon76-dig | Yes, you do |
| 03:35.45 | Corydon76-dig | must be? |
| 03:37.34 | *** join/#asterisk-dev jmesquita (n=jmesquit@200.170.114.149) |
| 03:41.30 | *** part/#asterisk-dev ratdesang (i=cramey@78-160-237-24.mvl.swc.static.gci.net) |
| 04:13.02 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 04:13.02 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Lost: Sanity Found: Banana -=- Automated Builds, thx file! - http://buildbot.digium.com |
| 05:05.57 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 05:41.41 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 06:14.46 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 07:45.24 | *** join/#asterisk-dev bkw_ (n=brian@adsl-70-234-165-123.dsl.tul2ok.sbcglobal.net) |
| 08:07.01 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 09:43.38 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 09:43.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:44.57 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 09:44.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 10:38.35 | tzafrir_home | hmm... I noticed that 'make clean' now fails if I don't have kernel source / headers |
| 10:38.43 | tzafrir_home | (if KSRC does not get set) |
| 10:39.13 | tzafrir_home | I has just broken a userspace-only build of Zaptel here in a chroot builder |
| 10:39.36 | tzafrir_home | (with the usual ugly workaround: make dist-clean || true) |
| 10:39.48 | tzafrir_home | I wonder if there's a smarter way |
| 11:27.33 | *** join/#asterisk-dev snuff-home (n=snuff-ho@C-61-68-136-239.bur.connect.net.au) |
| 12:10.11 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 12:18.04 | *** join/#asterisk-dev RoyK (n=roy@ip-183-20-149-91.dialup.ice.no) |
| 12:20.57 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 12:20.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:29.40 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 12:31.02 | *** join/#asterisk-dev qdk_ (n=qdk@195.242.194.42) |
| 12:51.17 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 12:51.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:32.52 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 13:32.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:23.12 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 14:23.12 | *** mode/#asterisk-dev [+o d3wayne] by ChanServ |
| 15:15.01 | *** join/#asterisk-dev joshaidan (n=brianj@S0106001c1023e838.tb.shawcable.net) |
| 15:35.34 | *** join/#asterisk-dev bkw__ (n=brian@ppp-70-128-106-102.dsl.tulsok.swbell.net) |
| 15:39.13 | *** join/#asterisk-dev jeffg (i=TGtVsxCv@pdpc/supporter/active/jeffg) |
| 15:48.58 | *** join/#asterisk-dev bkw__ (n=brian@ppp-70-128-106-102.dsl.tulsok.swbell.net) |
| 15:59.49 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 16:10.38 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:10.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:15.12 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 16:16.10 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 16:16.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:31.27 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 16:43.59 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 16:43.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:48.39 | *** join/#asterisk-dev seanbright-home (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |
| 17:04.58 | tzafrir_home | speaking of unnecessary D-Channel "up" and "down" messages: |
| 17:06.06 | tzafrir_home | with BRI PtMP, most providers tend to take the connection down between calls (after a timeout with no calls) |
| 17:06.36 | tzafrir_home | This is because they also provide power on that line for an optional ISDN phone |
| 17:07.45 | tzafrir_home | For that reason in bristuff the D-Channel "up" and "down" messages are demoted to a lower priority for the ptmp case |
| 17:16.34 | *** join/#asterisk-dev seanbright-home (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |
| 17:21.27 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 17:27.47 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:52.22 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 17:58.16 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 17:58.16 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 18:17.46 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 18:20.19 | kamanashisroy | hi, I am trying to play something when amd is detecting human or machine ........ I have added ast_streamfile() in the code , which seems non-blocking ....... does ast_streamfile() feed the channel or I need to call ast_waitstream() ...... Please let me know any kind of advice too :) |
| 18:23.16 | Cresl1n | IIRC, you need to call ast_waitstream to block until the stream is played |
| 18:25.42 | kamanashisroy | Cresl1n: thank you for your answer :). I cannot block amd to its test on the channel .... any way around ? |
| 18:26.11 | Cresl1n | you don't have to block by any means |
| 18:26.22 | Cresl1n | what's your problem exactly that you're trying to solve? |
| 18:26.55 | kamanashisroy | Cresl1n: I am trying to play file while amd is detecting answering machine .. |
| 18:27.12 | Cresl1n | ok |
| 18:27.25 | kamanashisroy | Cresl1n: I have put the ast_streamfile inside the processing loop of amd |
| 18:27.33 | kamanashisroy | Cresl1n: can I paste the code ? |
| 18:27.37 | Cresl1n | sure |
| 18:27.56 | Cresl1n | use pastebin.ca or something like that though |
| 18:28.03 | Cresl1n | don't paste in the chat room |
| 18:29.14 | kamanashisroy | Cresl1n: yes .. |
| 18:29.25 | file | I had to do some magic in speech_background in app_speech_utils.c to do that |
| 18:31.09 | kamanashisroy | Cresl1n: http://pastebin.com/m61343fc8 near line 218 .. |
| 18:31.28 | kamanashisroy | Cresl1n: the adds in the public pastebin sites take all my bw :-P |
| 18:31.37 | kamanashisroy | file: let me take a look at that .. |
| 18:31.55 | file | it plays a file but feeds the audio coming in elsewhere... |
| 18:32.12 | kamanashisroy | Cresl1n: 217 -> 227 ... they are doing the most of the things .. |
| 18:32.34 | kamanashisroy | file: means it feeds in the background thread ? |
| 18:33.14 | file | I don't know what you mean by that question... |
| 18:33.25 | kamanashisroy | Cresl1n: I did not use ast_waitstream(), because I thought that is blocking .. |
| 18:34.02 | kamanashisroy | file: OK .. let me think for some seconds :) , let me take a look at your code .... |
| 18:36.03 | kamanashisroy | file: speachbackground |
| 18:36.19 | file | SpeechBackground, yes |
| 18:38.02 | kamanashisroy | file: thanks for that great example .. I am trying like that ... I did not know openstream, applystream, playstream ... |
| 18:38.40 | file | well... that API wasn't exactly made to be used like SpeechBackground does, or how you want |
| 18:38.50 | file | but it works. |
| 18:39.58 | kamanashisroy | file: your helper function looks similar to ast_streamfile() ... so why not use that ? |
| 18:40.57 | file | I do not remember why not |
| 18:42.48 | kamanashisroy | file: OK .. but finally I did not get what is wrong with my code :( |
| 18:44.24 | file | you have to add code in that plays back the audio, you can't rely on any of the current API calls because they all block and toss away the audio |
| 18:44.37 | file | look at the part that says "Run scheduled stuff" |
| 18:45.19 | kamanashisroy | file: following ... |
| 18:45.42 | file | if I remember correctly that is all you need to do... |
| 18:47.33 | kamanashisroy | file: yes .. now that make sense of how I schedule .. |
| 18:49.21 | *** join/#asterisk-dev RoyK (n=roy@ti211310a080-5579.bb.online.no) |
| 19:01.42 | kamanashisroy | file: I know you have limited time, but it is fun if you check line, 231 , in http://nopaste.info/3a0118bea5.html |
| 19:03.46 | file | ha |
| 19:03.47 | file | did it work? |
| 19:04.22 | kamanashisroy | file: yes .. and I added a line checking if the stream ends and tried next file ... copied from your code ;) |
| 19:04.30 | file | cool. |
| 19:06.10 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 19:08.56 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:08.56 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:09.10 | Cresl1n | hey russellb |
| 19:09.44 | Cresl1n | Gotta question for you |
| 19:10.03 | Cresl1n | I found out that one of those crashes I was talking about last night was through the IAX code |
| 19:10.09 | Cresl1n | are you interested in seeing the backtrace? |
| 19:10.30 | russellb | sure |
| 19:10.34 | Cresl1n | ok |
| 19:10.49 | *** part/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 19:11.31 | Cresl1n | http://pastebin.ca/934284 |
| 19:11.44 | Cresl1n | terminated via Seg fault |
| 19:12.10 | Cresl1n | wasn't sure if that was a fault in the jitterbuffer or some interaction of chan_iax with the jitterbuffer |
| 19:12.55 | russellb | interesting |
| 19:12.58 | russellb | haven't seen that one before |
| 19:13.03 | Cresl1n | By the way, 305485 calls processed in the last 3 days on that machine |
| 19:13.05 | Cresl1n | :-) |
| 19:13.27 | Cresl1n | oh wait, closer to 4 days |
| 19:14.03 | puzzled | hi |
| 19:14.29 | Cresl1n | I can give you more information if you want it too |
| 19:14.32 | Cresl1n | I've got the core open right now |
| 19:15.22 | puzzled | what happened to zaptel-base.c? my patches are confused since it no longer seems to exist in 1.4.9.2 :) |
| 19:15.31 | puzzled | did it get merged into another file perhaps? |
| 19:15.58 | russellb | kernel/ dir |
| 19:16.18 | puzzled | doh off course. the big rearrangement. thanks |
| 19:16.20 | russellb | Cresl1n: (gdb) p frame->prev |
| 19:16.31 | tzafrir_home | BTW: svnmerge doesn't like this move |
| 19:16.45 | tzafrir_home | I had to use a "manual" svn merge |
| 19:16.45 | russellb | also, (gdb) p frame->next |
| 19:16.52 | russellb | well, nm on the 2nd one |
| 19:17.39 | Cresl1n | (gdb) frame 0 |
| 19:17.39 | Cresl1n | #0 jb_getall (jb=0x8d9c10, frameout=0x427d4340) at jitterbuf.c:409 |
| 19:17.40 | Cresl1n | 409 frame->prev->next = frame->next; |
| 19:17.40 | Cresl1n | (gdb) p frame->next |
| 19:17.40 | Cresl1n | Cannot access memory at address 0x100000020 |
| 19:17.40 | Cresl1n | (gdb) |
| 19:17.43 | russellb | nm again, i want frame->next too |
| 19:17.50 | russellb | how about prev |
| 19:18.08 | Cresl1n | (gdb) p frame->prev |
| 19:18.09 | Cresl1n | Cannot access memory at address 0x100000028 |
| 19:18.25 | russellb | that's nice. |
| 19:18.26 | russellb | :) |
| 19:18.31 | Cresl1n | the best :-) |
| 19:19.09 | Cresl1n | chan_iax is using thread local storage to cache frames? |
| 19:19.24 | russellb | well, it's possible that something in chan_iax2 is messing with the jitterbuffer without the pvt lock held ... |
| 19:19.26 | russellb | yeah, it is |
| 19:19.43 | russellb | not these frames though |
| 19:21.14 | Cresl1n | want me to try to pull anything out of any of the other stack frames? |
| 19:21.24 | Cresl1n | (gdb) frame 1 |
| 19:21.24 | Cresl1n | #1 0x00002aaaada89c60 in iax2_destroy (callno=50) at chan_iax2.c:2146 |
| 19:21.24 | Cresl1n | 2146 while (jb_getall(pvt->jb, &frame) == JB_OK) |
| 19:21.25 | Cresl1n | (gdb) p frame |
| 19:21.25 | Cresl1n | $1 = {data = 0x0, ts = 160, ms = 7720516, type = 8297728, next = 0xa0, prev = 0x2aaaadaa55a4} |
| 19:21.25 | Cresl1n | (gdb) p fram->next |
| 19:21.26 | Cresl1n | No symbol "fram" in current context. |
| 19:21.28 | Cresl1n | (gdb) |
| 19:22.04 | russellb | nah, that's enough |
| 19:22.05 | Cresl1n | (gdb) p frame->next |
| 19:22.05 | Cresl1n | $2 = (struct jb_frame *) 0xa0 |
| 19:22.05 | Cresl1n | (gdb) p frame->prev |
| 19:22.05 | Cresl1n | $3 = (struct jb_frame *) 0x2aaaadaa55a4 |
| 19:22.13 | russellb | i have a good enough idea of what potentially wrong ... |
| 19:22.19 | Cresl1n | ok |
| 19:22.31 | russellb | either the jb is getting poked at without the pvt lock held |
| 19:22.39 | russellb | or there is something more bizarre happening which would be hard to guess at |
| 19:27.52 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 19:31.02 | JunK-Y | 305 000 calls in 4 days, thats not bad! |
| 19:31.25 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 19:36.08 | Cresl1n | You betcha JunK-Y |
| 19:36.15 | Cresl1n | that's some good load testing |
| 19:37.03 | Cresl1n | and who says asterisk isn't carrier grade... :-D |
| 19:39.19 | JunK-Y | Cresl1n: you should publish these results more in details, such as codecs, protocols, etc |
| 19:39.31 | JunK-Y | im sure a lot of ppl would be interested by this. |
| 19:40.56 | file | have to get permission, or be extremely vague |
| 19:42.29 | Cresl1n | yeah |
| 19:48.25 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 19:48.25 | *** mode/#asterisk-dev [+o d3wayne] by ChanServ |
| 19:48.56 | *** join/#asterisk-dev janinge (n=janinge@ninge.net) |
| 19:49.33 | russellb | it's the d3wayne ! |
| 19:49.43 | d3wayne | hewwo |
| 19:51.36 | tzafrir_home | Cresl1n, any idea what's the way to go if I aim at destroying a span? |
| 19:51.49 | Cresl1n | huh? |
| 19:52.19 | tzafrir_home | at run time, close the D channel cleeanly |
| 19:52.35 | Cresl1n | oh, there isn't a good way right now |
| 19:52.43 | Cresl1n | it'd take some libpri work |
| 19:52.59 | tzafrir_home | Any hint on what kind of work? |
| 19:53.24 | Cresl1n | you'd have to close multiframe mode and release the TEI (if in PTMP mode) |
| 19:54.29 | tzafrir_home | are those at libpri level? |
| 19:54.41 | Cresl1n | oh yes |
| 19:54.46 | Cresl1n | most definitely yes |
| 19:54.53 | Cresl1n | we haven't even gotten to the chan_zap l evel |
| 19:54.55 | Cresl1n | *level |
| 19:55.01 | tzafrir_home | :-) |
| 19:55.05 | Cresl1n | those are the protocol things that would have to happen |
| 19:55.14 | Cresl1n | then you have to make chan_zap happy about it |
| 19:55.48 | tzafrir_home | hmm... I'll continue with the analog cleanup for now, then. |
| 19:58.33 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 19:58.33 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 20:03.26 | Juggie | its snowing like crazy here, 20cm since last night |
| 20:03.59 | Juggie | and it stopped early this morning |
| 20:04.09 | Juggie | now part2 is starting which is supposed to be another 30cm |
| 20:04.57 | russellb | i think it snowed here last night ... but it melted before i woke up. |
| 20:04.58 | russellb | :-p |
| 20:05.16 | Juggie | ya it did the storm we are seeing now started in alabama |
| 20:06.28 | Juggie | http://vortex.accuweather.com/adc2004/pub/includes/columns/community/2008/snoww.gif |
| 20:07.49 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-065-005-230-151.sip.lft.bellsouth.net) |
| 20:23.39 | *** join/#asterisk-dev jeffg (i=gXfHG96P@pdpc/supporter/active/jeffg) |
| 20:25.30 | *** join/#asterisk-dev bkruse (n=kruz@76.73.154.120) |
| 20:25.30 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 20:29.10 | *** join/#asterisk-dev bkruse (n=kruz@76.73.154.120) |
| 20:29.10 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 21:00.11 | *** join/#asterisk-dev seanbright-home (n=seanbrig@m535f36d0.tmodns.net) |
| 21:04.31 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 21:04.31 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Lost: Sanity Found: Banana -=- Automated Builds, thx file! - http://buildbot.digium.com |
| 21:10.14 | *** join/#asterisk-dev snuff-home (n=snuff-ho@C-61-68-136-239.bur.connect.net.au) |
| 21:29.43 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582907.dsl.bell.ca) |
| 21:33.37 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 21:34.55 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.4) |
| 21:36.54 | *** join/#asterisk-dev jeffg (i=isVqwcVV@pdpc/supporter/active/jeffg) |
| 21:54.49 | *** join/#asterisk-dev seanbright-home (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |
| 21:59.54 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 22:06.43 | JunK-Y | Juggie: any good discount for via rail, like last year? |
| 22:10.29 | seanbright-home | so in cdr_tds, there is this: |
| 22:10.43 | seanbright-home | AST_MUTEX_DEFINE_STATIC(tds_lock); |
| 22:11.09 | seanbright-home | any reason not to just use ast_mutex_t directly? |
| 22:11.44 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 22:12.14 | file | some platforms do not have a definition for an initialization value of a mutex lock |
| 22:12.59 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 22:14.00 | seanbright-home | so its safer to the use the pre-proc stuff? |
| 22:14.10 | file | AST_MUTEX_DEFINE_STATIC hides that fact so you don't have to worry about it... albeit the method it uses if there is no definition is also funky on some platforms |
| 22:14.22 | file | same goes for rwlock |
| 22:14.30 | seanbright-home | i just want to create a r/w lock in a struct definition |
| 22:14.39 | seanbright-home | *_STATIC ain't going to cut up |
| 22:14.44 | seanbright-home | s/up/it/ |
| 22:14.59 | file | then you use ast_rwlock_t and call ast_rwlock_init |
| 22:15.08 | seanbright-home | k |
| 22:16.01 | *** join/#asterisk-dev RoyK (n=roy@ip-192-19-149-91.dialup.ice.no) |
| 22:28.12 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 22:43.30 | *** join/#asterisk-dev CrashHD (n=CrashHD@76-14-102-131.rk.wavecable.com) |
| 23:02.05 | seanbright-home | so the only difference between a mutex and a rwlock is the granularity of the lock, yes? |
| 23:02.15 | seanbright-home | mutexes are all or nothing |
| 23:02.31 | seanbright-home | rwlocks can be read locked or write locked |
| 23:02.57 | file | you can *not* upgrade a read lock to a write lock either without unlocking... so the data may have changed |
| 23:03.13 | seanbright-home | that makes sense |
| 23:03.32 | seanbright-home | locks are overrated anyway |
| 23:03.34 | file | and they are not recursive, you can't lock a second time |
| 23:03.54 | file | the underlying data structure is very primitive and that totally makes it freak out... |
| 23:04.04 | seanbright-home | meaning "lock(); lock(); unlock(); unlock();"? |
| 23:04.11 | file | correct |
| 23:04.37 | seanbright-home | that's more of an implementation detail though, right? would one ever actually want to do that? |
| 23:04.47 | seanbright-home | err |
| 23:05.03 | seanbright-home | no, that was the right question |
| 23:05.28 | file | it... depends |
| 23:06.10 | seanbright-home | well it doesn't really make sense... |
| 23:06.32 | seanbright-home | unless you wanted to do rdlock(); wrlock(); unlock(); unlock() |
| 23:06.49 | seanbright-home | i could see that being useful |
| 23:06.58 | file | what about using an API call that locks, when you have the lock already? we do that with mutex locks in a few places |
| 23:07.23 | seanbright-home | sure |
| 23:07.31 | seanbright-home | but i'm saying there is no "legitimate" use of it |
| 23:08.08 | seanbright-home | you'd have to unlock before calling into the API, which does suck |
| 23:08.33 | file | you wouldn't have to, and if you did the data may change that you don't want to change... |
| 23:08.48 | seanbright-home | well you just said that locks aren't recursive |
| 23:08.56 | file | read/write locks are not. |
| 23:09.00 | seanbright-home | ohhh |
| 23:09.09 | seanbright-home | well that changes everything, file. |
| 23:09.09 | file | mutex locks as setup in Asterisk are. |
| 23:09.31 | file | the other solution is to have a variable that you pass in to indicate whether it needs to be locked or not |
| 23:10.09 | seanbright-home | locking a lock you own is a noop though for all intents and purposes though, yes? |
| 23:10.29 | file | mutex or rwlock? |
| 23:10.33 | seanbright-home | mutex |
| 23:10.47 | seanbright-home | rwlock = 'undefined behavior |
| 23:10.49 | seanbright-home | ' |
| 23:10.50 | file | it keeps a count, so as long as you unlock it as many times are you lock it... all is well |
| 23:11.02 | file | yeah, in most cases an rwlock will deadlock |
| 23:11.08 | seanbright-home | gotcha |
| 23:11.16 | seanbright-home | is that a bug in pthreads? |
| 23:11.23 | file | no, just implementation |
| 23:11.46 | seanbright-home | gotcha |
| 23:12.08 | seanbright-home | i feel smarter now, thanks. |
| 23:12.22 | seanbright-home | (not sarcasm) |
| 23:12.57 | seanbright-home | muffin? |
| 23:13.28 | seanbright-home | heh |
| 23:13.35 | file | now speaking from a programming perspective it is possible to write an rwlock implementation that is capable of a lot of this stuff... |
| 23:13.48 | file | it would just use a lot more memory |
| 23:15.12 | seanbright-home | because you'd need to keep track of the lock stack? |
| 23:15.19 | seanbright-home | ... for lack of a better word |
| 23:17.34 | seanbright-home | you in huntsville as well? |
| 23:17.43 | file | I am not. |
| 23:18.03 | seanbright-home | ahhh |
| 23:18.04 | russellb | but should relocate to Huntsville |
| 23:18.21 | seanbright-home | space camp! |
| 23:19.42 | seanbright-home | and i did not meet her online, amazingly |
| 23:19.51 | file | *gasp* |
| 23:20.02 | seanbright-home | i know, right. |
| 23:20.31 | seanbright-home | she's 35 though... so i have to be an adult or something |
| 23:22.03 | russellb | being grown up is lame |
| 23:22.17 | file | russellb: what's the countdown at? |
| 23:23.19 | russellb | 4 weeks from today |
| 23:23.27 | file | scary! |
| 23:23.29 | russellb | 4 weeks and ... 5 minutes |
| 23:23.30 | russellb | O.O |
| 23:23.34 | russellb | wait, no |
| 23:23.37 | russellb | less than that ... silly time zones |
| 23:24.11 | russellb | 3 weeks, 6 days, 23 hours, and 5 minutes |
| 23:24.18 | file | eep |
| 23:27.23 | seanbright-home | i agree |
| 23:27.42 | seanbright-home | oh how i wish i was 19 again |
| 23:27.54 | seanbright-home | things were so easy then... the world made sense... *sniffle* |
| 23:27.55 | seanbright-home | heh |
| 23:30.22 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 23:32.18 | russellb | seanbright-home: good luck! |
| 23:32.25 | russellb | seanbright-home: tell her about nmenuselect!!! |
| 23:32.30 | russellb | she'll totally think that is hot |
| 23:37.21 | mvanbaak | lol |
| 23:39.10 | *** join/#asterisk-dev putnopvut (n=putnopvu@76.29.245.9) |
| 23:39.10 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 23:48.37 | snuff-home | mm no love from nmenuselect for me |
| 23:49.04 | putnopvut | :( |
| 23:50.06 | snuff-home | http://www.pastebin.ca/934646 |
| 23:51.05 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 23:54.09 | *** join/#asterisk-dev jeffg (i=LmIqKQFm@pdpc/supporter/active/jeffg) |
| 23:59.52 | putnopvut | snuff-home, run_menu is in menuselect.h, that's quite odd that there's the linking error. |
