This exact deadlock situation that I observed can't happen in trunk due to the
authorRussell Bryant <russell@russellbryant.com>
Tue, 25 Jul 2006 19:51:31 +0000 (19:51 +0000)
committerRussell Bryant <russell@russellbryant.com>
Tue, 25 Jul 2006 19:51:31 +0000 (19:51 +0000)
commitd86d8ebdffa833fea2b46212bb05752662233b61
treeca901bec7b5af2b9ed8df4886434c0dc38ac6aa3
parent1bb760f3471f742730b9cfa91f2301060490c124
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: https://origsvn.digium.com/svn/asterisk/trunk@38201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_zap.c