Hi, sorry for the late reply, I'm back here again.
Thanks, I'm going to apply your patch with a little change. This method
should not return true if the channel has received null HTTP context,
while WaitOne() just returns true unless it goes timeout.
As for properties patch, I already made a
Hi again,
I'm just going through my outstanding local changes against the
latest CVS. Did you have chance to revisit the AutoResetEvent issue as
mentioned below? I've attached a new patch against the latest revision
to show the changes.
Also, I don't think the properties patch
After examining the patch, I have applied some parts of your patch.
-wait = new AutoResetEvent (false);
-source.ListenerManager.GetHttpContextAsync (timeout,
HttpContextAcquired);
-if (wait != null) // in case callback is done before
WaitOne()
The problem I was trying to fix was that it's possible for wait to be
set to null after:
if (wait != null)
and before:
wait.WaitOne(...)
causing a null reference exception.
Looking at MSDN it sounds like an AutoResetEvent should remain signalled
until a thread calls WaitOne? The problem is
The included patches fix the following:
multithreaded_fixes.patch: ObjectDisposedException,
InvalidOperationException(Another async TryReceiveRequest operation is
in progress) and other multithreaded timing fixes. Also includes
change to make GET ?wsdl case insensitive.
Hello,
Thanks for the patch. They are looking like a great set of attempts for
cool bugfixes :) However there is a lot of other changes that your
description cannot explain. So, please first split the changes into
further smaller patches for each purpose, and give explanation for each
Hi again,
As for the properties test case, never mind. I happened to get one at
hand (as my reply on DestinationUnreachable implies).
Atsushi Eno
On 2010/03/23 21:49, Atsushi Eno wrote:
Hello,
Thanks for the patch. They are looking like a great set of attempts
for cool bugfixes :) However
Ok, no problem. I can break them down more.
You're right, I can provide no guarantees about the Thread.Sleep
removal! But it could have been related to locking registered_channels
instead of pending? I did quite a bit of multithreaded testing, and
there were no problems; but I take your
I'll apply your changes only in split form. And I won't apply any
unnecessary changes unless everything got sorted out appropriately right
now, as they'd rather bring mess on applying incremental changes.
So, I'll skip your properties changes and 2) I'll leave Thread.Sleep()
until I test
