buggy asynchronous webClient

[=?Utf-8?B?YmlsbCB0aWU=?=]

An authoritative source claims out-of-the-box asynchronous "WebClient' s
implementation is flawed" in .Net 3.0.

Was it fixed in .Net 3.5 or .Net 3.5 SP1?

Thank you.

[Jon Skeet [C# MVP]]

On Oct 14, 10:38*am, bill tie <bill...@discus sions.microsoft .com>
wrote:

An authoritative source claims out-of-the-box asynchronous "WebClient' s
implementation is flawed" in .Net 3.0.

Was it fixed in .Net 3.5 or .Net 3.5 SP1?

Without having any information about what the flaw was, how could we
tell? Can you give us more information about this "authoritat ive
source"?

Jon

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

I have no experience with the book, nor this method, but I found the quote
here:

http://www.albahari.com/threading/threading.pdf

page 49, under "Asynchrono us Events".

"Jon Skeet [C# MVP]" wrote:

On Oct 14, 10:38 am, bill tie <bill...@discus sions.microsoft .com>
wrote:

An authoritative source claims out-of-the-box asynchronous "WebClient' s
implementation is flawed" in .Net 3.0.

Was it fixed in .Net 3.5 or .Net 3.5 SP1?

Without having any information about what the flaw was, how could we
tell? Can you give us more information about this "authoritat ive
source"?

Jon

[Peter Duniho]

On Tue, 14 Oct 2008 04:24:01 -0700, Family Tree Mike
<Fa************ @discussions.mi crosoft.comwrot e:

I have no experience with the book, nor this method, but I found the
quote
here:

http://www.albahari.com/threading/threading.pdf

page 49, under "Asynchrono us Events".

Good find. Only the OP can say for sure if that's the reference they're
talking about, but it seems like a likely candidate. :)

As for the statement itself, I can't confirm or refute it for .NET 3.0,
not having that installed at the moment. In the latest version, looking
at it with Reflector, the only thing that pops out as a potential issue
that I can see is that it possible tries to resolve the URI before
returning. But I'd have to spend more time looking at it to be sure (I'm
just skimming through it).

If that's in fact the case, I suppose to some extent that could be
considered a bug. After all, you do expect the asynchronous call to
return immediately, but if it wastes time trying to look up the URI, that
could take awhile, especially if there's a problem with the network and
you wind up waiting on a timeout.

It's an interesting question. Of course, if that is indeed what
HttpWebClient is doing, it's easy enough to work around by making the call
to DownloadStringA sync(), etc. itself asynchronously (note that WebClient
itself simply relies on the concrete sub-class implementations , so each
implementation may or may not have the same flaw...I've only looked the
HttpWebClient version).

Pete

[=?Utf-8?B?YmlsbCB0aWU=?=]

Good find. Only the OP can say for sure if that's the reference they're

talking about, but it seems like a likely candidate. :)

Indeed, that's what it is.

It's too bad heavyweights Jon Skeet and Peter Duniho are unable to pronounce
on a possible fix authoritatively . :-) I shall have to implement a
work-around.

[Jon Skeet [C# MVP]]

On Oct 14, 2:33*pm, bill tie <bill...@discus sions.microsoft .com>
wrote:

Good find. *Only the OP can say for sure if that's the reference they're *
talking about, but it seems like a likely candidate. *:)

Indeed, that's what it is.

It's too bad heavyweights Jon Skeet and Peter Duniho are unable to pronounce
on a possible fix authoritatively . :-) I shall have to implement a
work-around.

Well now that we know what you're talking about, it's somewhat easier
to address your original question. In particular, I'll ping off a mail
to Joe Albahari to see if he's aware of any workarounds or
improvements. (Assuming I remember... kinda busy right now.)

Jon

[Peter Duniho]

On Tue, 14 Oct 2008 06:43:10 -0700, Jon Skeet [C# MVP] <sk***@pobox.co m>
wrote:

[...]

>It's too bad heavyweights Jon Skeet and Peter Duniho are unable to
pronounce
on a possible fix authoritatively . :-) I shall have to implement a
work-around.

Well now that we know what you're talking about, it's somewhat easier
to address your original question. In particular, I'll ping off a mail
to Joe Albahari to see if he's aware of any workarounds or
improvements. (Assuming I remember... kinda busy right now.)

At the very least, it'd be nice to know in what way specifically that and
other methods _aren't_ actually completely asynchronous. I didn't spend
enough time in Reflector to feel that I could say for sure my guess was
correct. He made the statement, so he should be able to explain precisely
what the issue is.

That said, whatever the specific problem might be, it seems like at least
some workarounds are pretty obvious. As I mentioned before, one could
simply execute the DownlownStringA sync() method asynchronously. For
example:

WebClient client = ...;

new Action(delegate { client.Download StringAsync(... );
}).BeginInvoke( );

Adding whatever error-handling and notification might be appropriate, of
course.

For that matter, if you want an event-based notification pattern, but
don't have to use the event in the WebClient itself, you could just call
DownloadString( ) synchronously, but from a BackgroundWorke r, handling the
BackgroundWorke r.RunWorkerComp leted event instead of
WebClient.Downl oadStringComple ted.

Pete