[asterisk-dev] 1.4.18-rc4 ast_waitfordigit seemingly taking too long

[Norman Franke]

I've been testing Asterisk 1.4.18-rc4 for several days and one things  
got me puzzled. While locking contention seems resolved from 1.4.17,  
another odd thing came up in testing. I'm using Debian Etch with  
Linux Kernel 2.6.23.11. I did have DEBUG_THREADS and DETECT_DEADLOCKS  
enabled, as well as MALLOC_DEBUG and DONT_OPTIMIZE.

In an app I've been working on, I call ast_waitfordigit in a tight  
loop that waits for a variable (an int) set by another thread to  
change or events via ast_waitfordigit. I call it with a 1000 ms  
timeout. During times of heavy use, I find that calls are waiting in  
ast_waitfordigit much longer than they should. In many cases, the  
variable has been set so the loop should exit (and it can't restart)  
which leads me to ast_waitfordigit. I can verify this using gdb (I  
generated a core file and analyzed it after the fact.) About 10 of 29  
threads waiting in ast_waitfordigit could exit when ast_waitfordigit  
terminates. None did for at least 20 seconds.

The odd thing is that looking at the "start' variable in  
ast_waitfor_nandfds (called by ast_waitfordigit), all 29 threads were  
started with in 2 ms of each other, many within a few ns. This seems  
highly suspect. Perhaps the call to ast_channel_lock in  
ast_waitfor_nandfds was blocking (in the poll syscall) way, way too  
long. However, this didn't appear to be the case in gdb since none  
were stuck there. Perhaps ast_channel_lock somehow synchronized the  
threads?

Any ideas?

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080206/5756ce21/attachment.htm