No subject

ast_waitfor_nandfds is actually how long to read from the file descriptor. 
It has nothing to do with how long to wait for a lock, and I don't see any
deadlock avoidance in autoservice_run.

My first patch *avoided* this problem by not passing a channel to the
pbx_find_extension inside of ast_parking_ext_valid.  That would prevent
ast_autoservice_start/stop from executing at all.  Russell stated clearly
that this would not be accepted as a final solution as autoservice needs to
be applied on these channels to handle cases of long return times (i.e.
Database lookups).

The second patch attempts to unlock p->owner before the call to
ast_parking_ext_valid, and seems to prevent the deadlock above. However,
after a lot more testing, this doesn't prevent other deadlocks from
happening (like the one you show in 18403-kkm-locks-1.txt)  Even trying to
relock p->owner after the ast_parking_ext_valid call I still get deadlocks.
 That makes me think that I am looking entirely in the wrong area, or there
is something much larger going on here that I haven't found yet. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-24 17:47 jthurman       Note Added: 0129955                          
======================================================================