<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Jason,<br>
<br>
ok, would be great to sort it out properly, thanks for your time!<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 12/05/15 10:10, Jason Penton wrote:<br>
</div>
<blockquote
cite="mid:CALoGXNVU1p6ZDd47O2jhQwg7JM_GrkgSf+OUay-Q_cpSEUqT0w@mail.gmail.com"
type="cite">
<div dir="ltr">Hey Daniel,<br>
<br>
Okay great, let me look into this. It will be great if we have
one less mutex to worry about ;) - If not required I will remove
and commit.
<div><br>
</div>
<div>Cheers</div>
<div>Jason</div>
</div>
<br>
<div class="gmail_quote">On Mon, 11 May 2015 at 09:55
Daniel-Constantin Mierla <<a moz-do-not-send="true"
href="mailto:miconda@gmail.com">miconda@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jason,<br>
<br>
over the weekend I pushed a patch that disables the use of
dedicated<br>
mutex for t_continue(). It can be enabled by defining
ENABLE_ASYNC_MUTEX.<br>
<br>
While investigated some reports of crash when removing from
time, I<br>
found the potential of a race when t_coninue() is executed at
the time<br>
the fr_timer for suspended transaction elapsed. The timer
process will<br>
get the transaction out and remove it from timer under the
reply lock<br>
and the worker doing t_continue() will get it out under the
async lock.<br>
<br>
I looked at the commit you did when introducing the dedicated
async<br>
mutex, the note being:<br>
<br>
- "dedicated lock to prevent multiple invocations of
suspend on<br>
tz (reply lock used to be used)"<br>
<br>
Perhaps tz is tx and stands for transmission - however, the
reply lock<br>
should be safe for this case as well. Moreover, the continue
is like the<br>
suspended branch got a reply and transaction continues
processing, which<br>
implies the reply lock is aquired (like execution of
failure_route,<br>
which can also happen if fr_timer elapses before t_continue()
is executed).<br>
<br>
Given those, I don't see anymore a reason for dedicated async
mutex.<br>
Also, it protects to races of using two mutexes, which can
easily lead<br>
to deadlocks (e.g., one process acquires the reply lock and
tries to get<br>
the async lock while another one wanted first the reply lock
and later<br>
the async lock).<br>
<br>
For now I disabled the code with defines, as I wanted to
discuss and be<br>
sure I haven't overlooked any issue you tried to avoid with
the<br>
dedicated mutex. Let me know what you think about.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
--<br>
Daniel-Constantin Mierla<br>
<a moz-do-not-send="true"
href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a>
- <a moz-do-not-send="true"
href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a><br>
Kamailio World Conference, May 27-29, 2015<br>
Berlin, Germany - <a moz-do-not-send="true"
href="http://www.kamailioworld.com" target="_blank">http://www.kamailioworld.com</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - <a class="moz-txt-link-freetext" href="http://www.kamailioworld.com">http://www.kamailioworld.com</a></pre>
</body>
</html>