On Fri, 13 Jul 2007 01:20:26 -0700 (PDT), Grey Man wrote > > ----- Original Message ---- > > From: Kaloyan Kovachev <[EMAIL PROTECTED]> > > To: Asterisk Developers Mailing List <[email protected]> > > Sent: Sunday, 8 July, 2007 6:21:29 PM > > Subject: Re: [asterisk-dev] Real-time call control for Dial app > > > >> Hi, > >> > >> In doing some further testing of the recheck/call control patch a warning > >> is > popping up about a blocked thread. > >> > >> channel.c:1608 ast_waitfor_nandfds: Thread xxx Blocking 'SIP/xx-xxx', > already blocked by thread xxx in procedure ast_waitfor_nandfds > > > >Hi, > >Haven’t tested with AGI, but SQL query may also take longer than a second or > >two and that’s why i am using separate ‘call control’ thread – not to > >interrupt the audio. Also there are no any locks in the thread during the > >execution of the application. > >I have tested (some time ago) not returning from the application for a long > >time (with simple sleep 100 application) and there where no ‘blocking’ > >messages, so probably there is something in the script itself (or in the way > >FastAGI works, which i am not common with), which is causing the lock. > > > >P.S. > >I'we got similar messages while trying to play the warning sounds from > inside > >the control thread. > > Hi Kaloyan and All, > > You were right about the thread locking issue being related to the AGI application. The original thread executing the dial_exec_full needs a lock on the original channel somewhere in ast_channel_bridge. Then the Agi application also requests a lock on the same channel in agi_exec_full in res_agi.c. As you indidcated I also don't think it's a huge deal as I haven't been able to cause any serious malfunctions by stalling or killing my fastagi application. The worst thing that seems to be able to happen is if the Agi application hangs and coincides with the time the original dial thread should be hanging it up due to the time limit expiring. In that case the call will not be hungup until the Agi application is interrupted by a timeout signal, I'm not sure exactly what the timings are but I think the hung thread will get interrupted after about 20 to 30s so in the worst case the call would go 30s over. > > One other concern that cropped up is the impact the additional thread load could have on the Asterisk audio processing. Each in progress channel now has two threads, I'm wondering if the thread extra context switching could cause a load problem. Asterisk and/or the libpthread code does seem very efficient at switching amongst threads so I'm hoping it will be alright with the doubling of threads. I'd be very interested to know if anyone has any insights into the possible impact of introducing an extra thread for every call in order to do the real-time call control. > Hi again, i guess Asterisk is not used for prepaid applications too much, or more likely the risk of overused account is just ignored (there are providers with 'pay as go' services with which i had negative balance for a while). Even separate thread for each call bridge is not the best way and adding another one is not a good idea - agree, but the call control thread is sleeping most of the time, so it shouldn't cause too much problems. Unfortunately my C skills (and available time) are not enough to make (my long term idea) a single call control thread for which each call will just register and which will also be responsible for the warning messages on that call instead of the bridging thread itself. I think this is the way to go, but for now this is at least some way to control the call duration after it has started.
P.S. For the warning messages it plays (actually whispers) successfully the one for the calling channel, but still couldn’t (had the time to) make it to play to the called or simultaneously to both channels if configured. > Regards, > > Greyman. > > ____________________________________________________________________________________ Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. > http://au.docs.yahoo.com/mail/unlimitedstorage.html > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
