<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Matthias Radestock wrote:
<blockquote cite="mid:4A2EE289.3080505@lshift.net" type="cite">Thanks
for the patch. If you don't mind, we'll look into this in a few weeks
when the person who wrote the original code is back from holidays.
<br>
</blockquote>
Certainly. I'll put my patch into production today, and will send you
a new patch if I run into problems.<br>
<br>
<blockquote cite="mid:4A2EE289.3080505@lshift.net" type="cite">On the
latter point, the locks look a bit too coarse-grained to me, covering
activities that can take an indeterminate amount of time, such as
interactions with the server. That may be unavoidable, but without
understanding every single detail of the code it's hard to be sure.
<br>
</blockquote>
They are a bit heavy-handed. It is very possible that Subscription /
SimpleRpcServer could be
refactored to maintain thread safety with finer locks. I was wanting
to make minimal changes, so I didn't go that route. I walked through
it with another co-worker for a sanity check, and
locking those large blocks seemed the only way to ensure correctness in
these cases:<br>
<ol>
<li>calling Close() while the subscription is blocked waiting for a
message</li>
<li>calling Close() while the server is processing a message</li>
<li>calling Close() after the subscription has fetched a message but
before the server has started processing it<br>
</li>
</ol>
I'm looking forward to hearing from the original author next month.<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606
Office: 352-335-6500 x 124
Fax: 352-335-6506</pre>
</body>
</html>