<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/1557/">https://reviewboard.asterisk.org/r/1557/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On November 3rd, 2011, 12:45 p.m., <b>David Vossel</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I understand that back-porting the do_monitor loop optimizations from Asterisk 10 resolves this issue, but (correct me if I am wrong) this seems like it is much more than is necessary just to fix the deadlock at hand.  That optimization came before 1.8.0.0 was officially released, but we choose not to include it into 1.8 at that time because 1.8 was already branched and the improvement appeared to be primarily optimization related (the optimization is insanely awesome btw)...  While the optimization looks sane, none of this code has yet to be proven in a production release of Asterisk.   I don&#39;t want to run the risk of introducing a regression for something like this, especially when we are in release candidate phase for Asterisk 1.8.8.  We need a simple and solid fix for this blocker that does not introduce any unnecessary complexity.</pre>
 </blockquote>




 <p>On November 3rd, 2011, 1:08 p.m., <b>schmidts</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">i only suggest this after your comment about the own container for dialogs which need to be destroyed, cause this part of code is allready written and submitted.
you are right about the reasons why this patches didnt came into 1.8 and i didnt know this issue is a blocker for 1.8.8
if you only add a container for dialogs to destroy then its not necessary to use the full patch cause the rtp timeout would be done in the normal loop over all dialogs.

but if i understand the locking order right as described above you want to remove 2a so the temporary dialog could be inserted into the dialog container. this could only work if you dont iterate over all dialogs and imho without this rtptimeout checks wouldnt work anymore.

i hope i understand something wrong and there is an easier way to solve this cause i really understand why you want a simple fix without any unnecessary complexity.</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I was planning to add a container like dialogs_needdestroy after dvossel&#39;s comment and before your suggestion.  The primary difference would be that anything put in that container would be unconditionally destroyed after the do_monitor ao2_callback to dialog_needdestroy search put the dialogs in the to_destroy container.</pre>
<br />








<p>- rmudgett</p>


<br />
<p>On November 3rd, 2011, 1:12 p.m., rmudgett wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers and David Vossel.</div>
<div>By rmudgett.</div>


<p style="color: grey;"><i>Updated Nov. 3, 2011, 1:12 p.m.</i></p>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Timing between dialog destruction and a MWI event sending a message could result in a deadlock.

Order of events causing deadlock:

1a) The event subscription system calls the registered callbacks with its list RWLOCK held.
1b) The SIP monitor checks for dialogs needing destruction.  It does an ao2_callback that holds the dialogs container lock while searching for dialogs to destroy.
2a) The event subscription SIP callback needs to create a temporary dialog to send out the MWI notification.  That temporary dialog needs to be inserted in the dialogs container so it must wait.
2b) The dialog search finds a dialog to destroy and as a result releases the last reference for a peer.  The peer destructor attempts to get the subscription RWLOCK but must wait.
3) deadlock
</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">It compiles. :)</pre>
  </td>
 </tr>
</table>



<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>


 <a href="https://issues.asterisk.org/jira/browse/ASTERISK-18747">ASTERISK-18747</a>


</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>/branches/1.8/channels/chan_sip.c <span style="color: grey">(343335)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/1557/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>