[asterisk-dev] Real-time call control for Dial app

[Grey Man]

> ----- Original Message ----
> From: Kaloyan Kovachev <kkovachev at varna.net>
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> 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.

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