aboutsummaryrefslogtreecommitdiffstats
path: root/include/asterisk/lock.h
diff options
context:
space:
mode:
authorrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2008-05-13 21:17:23 +0000
committerrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2008-05-13 21:17:23 +0000
commitcffbde648458383efb0930d428fc72960e0af9d7 (patch)
tree2941309fd74231437678cc69252dbd397022af85 /include/asterisk/lock.h
parent03a5a3694a37cf03392bfc7917f4574039b1e1e9 (diff)
Fix a deadlock involving channel autoservice and chan_local that was debugged
and fixed by mmichelson and me. We observed a system that had a bunch of threads stuck in ast_autoservice_stop(). The reason these threads were waiting around is because this function waits to ensure that the channel list in the autoservice thread gets rebuilt before the stop() function returns. However, the autoservice thread was also locked, so the autoservice channel list was never getting rebuilt. The autoservice thread was stuck waiting for the channel lock on a local channel. However, the local channel was locked by a thread that was stuck in the autoservice stop function. It turned out that the issue came down to the local_queue_frame() function in chan_local. This function assumed that one of the channels passed in as an argument was locked when called. However, that was not always the case. There were multiple cases in which this channel was not locked when the function was called. We fixed up chan_local to indicate to this function whether this channel was locked or not. The previous assumption had caused local_queue_frame() to improperly return with the channel locked, where it would then never get unlocked. (closes issue #12584) (related to issue #12603) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116038 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'include/asterisk/lock.h')
0 files changed, 0 insertions, 0 deletions