[asterisk-dev] AST_FRAME_NULL - what is it?

Bryan Field-Elliot bryan+asterisk-dev at nextalarm.com
Fri May 29 12:04:39 CDT 2009


Thanks Tilghman and Moises for your advice,

Before I got your message about calling ast_channel_lock, I added the  
following code and it seems to relieve the symptoms by a large factor  
(not quite 100%, but maybe by 98%):

if (frame->frametype == AST_FRAME_NULL) {
	// yield
	usleep(1);
}

Do you see anything wrong with this approach which I might pay for  
down the road?






On May 29, 2009, at 9:42 AM, Tilghman Lesher wrote:

On Friday 29 May 2009 11:08:59 Moises Silva wrote:
>> That makes sense. Even before I dive in to the code to try to find  
>> out
>> *what* is hanging on to the channel lock, is there some coding
>> technique I can apply to my code, to correctly wait for the lock,  
>> and/
>> or yield to other threads, before I call ast_read, so that I can be
>> certain I won't get a AST_FRAME_NULL in return?
>
> ast_channel_lock(chan) will block until it can get the lock, so if you
> use that before reading you are certain ast_read will get it as well
> (mutex in Asterisk are recursive). However you have not even confirmed
> that my guess (ast_read not being able to get the lock) is true, first
> I think you should confirm that. If you are developing also be sure to
> compile Asterisk as follows
>
> ./configure --enable-dev-mode
> make menuselect
> -> compiler flags
>     -> DONT_OPTIMIZE, DEBUG_CHANNEL_LOCKS, DEBUG_THREADS
>
> then you have cli commands such core show locks, core show threads
> etc, grep those options in Asterisk source code for more info about
> what they do. AFAIR DEBUG_CHANNEL_LOCKS will give you enough info
> about who is holding the lock and where was taken.

One additional caveat -- make sure you aren't holding any locks when you
call ast_channel_lock or you may initiate a deadlock situation.
DEBUG_CHANNEL_LOCKS is NOT what you want; rather, you want  
DEBUG_THREADS,
as this enables the CLI command "core show locks", which will show you  
all
locks presently held at a snapshot in time.

-- 
Tilghman

_______________________________________________
--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




More information about the asterisk-dev mailing list