diff options
author | russell <russell@f38db490-d61c-443f-a65b-d21fe96a405b> | 2006-07-25 19:51:31 +0000 |
---|---|---|
committer | russell <russell@f38db490-d61c-443f-a65b-d21fe96a405b> | 2006-07-25 19:51:31 +0000 |
commit | ea73c30141baf0a943bce84b9002e7d606e2d08e (patch) | |
tree | ca901bec7b5af2b9ed8df4886434c0dc38ac6aa3 /channels/chan_zap.c | |
parent | 81146a9f92693f7c11989e4c4f865c94b1b9deb6 (diff) |
This exact deadlock situation that I observed can't happen in trunk due to the
recent hold changes so that MOH is not started on the bridged channel directly.
However, the change is still not a bad idea.
Merged revisions 38200 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r38200 | russell | 2006-07-25 15:43:38 -0400 (Tue, 25 Jul 2006) | 6 lines
This resolves a deadlock that a tech support customer was getting frequently
when his users would answer call waiting. If another thread is currently
holding the zt_pvt lock for the first channel, unlock both channels and let
asterisk retry the native bridge, just like what is done for the second channel
directly below these changes.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@38201 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'channels/chan_zap.c')
-rw-r--r-- | channels/chan_zap.c | 8 |
1 files changed, 7 insertions, 1 deletions
diff --git a/channels/chan_zap.c b/channels/chan_zap.c index 3aa84d006..b0578e776 100644 --- a/channels/chan_zap.c +++ b/channels/chan_zap.c @@ -3117,7 +3117,13 @@ static enum ast_bridge_result zt_bridge(struct ast_channel *c0, struct ast_chann oc0 = p0->owner; oc1 = p1->owner; - ast_mutex_lock(&p0->lock); + if (ast_mutex_trylock(&p0->lock)) { + /* Don't block, due to potential for deadlock */ + ast_mutex_unlock(&c0->lock); + ast_mutex_unlock(&c1->lock); + ast_log(LOG_NOTICE, "Avoiding deadlock...\n"); + return AST_BRIDGE_RETRY; + } if (ast_mutex_trylock(&p1->lock)) { /* Don't block, due to potential for deadlock */ ast_mutex_unlock(&p0->lock); |