This bug is causing my app to pause for about 0.3s when Dispose() is called, when I'm running a www = new WWW(url) in the background in a Coroutine.

It says the priority is a 3, 'work around is possible', so I'm guessing its not going to get fixed soon, and by looking at the submit date.

Can someone post a workaround, then, to stop this from happening?

Thanks.

Still a bug in Unity 4.5.3. I do not get a deadlock as @Postelzhuk reports, but in both the editor and in Android app, calling WWW.Dispose causes a total freeze up (i.e. 0 frames per second) for 2-4 seconds. I get the same result if I wrap the WWW instance inside a using () clause, and do not call Dispose directly.

I am attempting to use Dispose to kill downloads that are taking "too long", so I can reschedule them for later, an fetch more important assets first.

If I do not call Dispose (), the app will not hang, but as I understand it, this leaves the download still running in the background, hogging network speed and probably socket handles.

Here is my case:
+ Device A is a Mobile Hotspot (using EDGE as a source).
+ Device B is connected to the Device A hotspot.
+ Turn off EDGE on Device A
+ Send request from Device B
+ Call WWW.Dispose() and get dead lock.

I got error when I using "dispose" after "WWW.LoadFromCacheOrDownload"

There is no problem with "new WWW(url)"