Is UnityWebRequest threaded to background?

I can see that it has IEnumerators to be used in Coroutines.

I'm asking if the code between the yields is running on a separate background thread, or still blocking the main thread.

The predecessor (WWW) was also Coroutine based, but still the calls between yields freezed the main thread. It is really annoying, when a web service is lagging / not available.

 

Coroutines run on the main thread, unless you implement a mechanism that allows to jump back and forth between threads.
Back to the usual coroutines: If your coroutine keeps "freezing" your main thread, you're either executing a very expensive piece of code, you're hanging in a loop or you're calling a blocking operation.

 

Thanks for getting back!

It is not me in some cases: a while back a 3rd party analytics we used were implemented using WWW calls, that had the game frozen every minute as they dispatched a vast amount of analytics events.

Coroutines are just kind of a neat helper, but they are basically calls on the main thread on every frame. If you put in a System.Threading.Thread.Sleep(5000); in any Coroutine, the game will freeze for 5 seconds. This kind of stuff does not happen, if you process heavy stuff on a background thread.

And I definitely want my networking that kind of stuff. If UnityWebRequest is running on the main thread, then it is not for me either. For now, RestSharp seems fine: it uses .NET APIs nicely dispatched to a background thread.

Anyway, I'm still curious whether UnityWebRequest is requesting on a background thread, or not.

 

That's what I said above. Everything you put there (unless you do thread jumping) is executed on the main thread.

Now in order to benefit from coroutines, the web requests are surely run in the background in parallel. The async operation you keep yielding is implemented in such a way that it polls an internal state. Once the request finished, the state changes and with the following state query, the yielding of that operation will be complete and the program will be allowed to proceed.

If it wasn't using any backgrond thread, you'd totally block the main thread by sending a request, which would render the usage of coroutines ineffective and superfluous.

You could even write your own yield instruction (CustomYieldInstruction or a plain IEnumerator) and do that in your own way.

 

In short: I've seen WWW classes blocking the main thread, so I don't prefer using them. I'm just asking whether UnityWebRequest is the same. I'm hoping for an answer from someone who is involved in implementing UnityWebRequest (sure it won't download 1 GB synchronously, but polling for progress, or network reachability / IP availablility / whatever network test still could be main threaded somewhere within).

Anyway, RestSharp is threaded by default, also the API is kind of intuitive, like below.

Code (CSharp):

1. var client = new RestClient("http://maps.googleapis.com");
2. var request = new RestRequest("maps/api/geocode/json", Method.GET);
3. request.AddParameter("address", "Siofok");
4. var handle = client.ExecuteAsync(request, response =>
5. { Debug.Log(response.Content); });

 

@Aurimas-Cernius Yay, thanks for the information! Is it still hooked up to NSURLRequest / NSURLConnection / NSOperationQueue classes on iOS? Or is it using .NET WebRequest classes on every platform?

 

Today I made a tons of test with measuring CPU time / with various server response times / concurrency / network availability, and saw no significant amount of lag indeed.

 

What platforms is RestSharp compatible with?

 

@Chris-HG iOS, Android, Windows Phone, and probably more. I don't know exactly, lookup their resources.

However, RestSharp complicates main thread calls somewhat from async callbacks, so after I made the corresponding test, I've stuck with UnityWebRequest.

 

Just write a very generic dispatcher and trigger it in a thread-safe manner every x frames or x seconds.
That does only make sense though if you really prefer RestSharp over Unity's implementation. As an alternative, you could see this as an opportunity to give some valuable feedback about your concerns or issues with the current implementation.

 

There is a way to control the number of threads of any WebRequest operation?