在同步方法中等待异步方法而不阻塞线程

Question

I have some code that runs under Unity Game Engine. Parts of that code is also running on the server (IIS 8.0, Azure Cloud). Since Unity only supports a subset of .Net Framework (3.5 or something close to it) it doesn't support at the moment async / await pattern.

Naturally my server is fully built by using async methods. The problem is that Unity code needs to call some of my server methods and it cannot use the await keyword. I need to expose some basic methods for the Unity code so it can call them on the server.

For example I could have the following code:

   Public bool Save()
   {
       Task.Run(async() => await PlayerService.SavePlayer());
       return true;
   }

This of course runs nicely, but I need to make sure that the method save doesn't return before the save has completed. Now how do I wait for that task to run to the end before it returns to the method Save()? Also do this without blocking the thread? Blocking the method is fine.

Btw. there is a ton of await calls in side the PlayerService.SavePlayer();

Also there is the problem of synchronization context, it seems that when calling the initial call through SignalR it doesn't like if the context changes.

Just to clarify how SignalR is involved here is an example of the pattern:

SignalR gets a message -> This loads a instance of the model (Unity code) from the memory -> The model then thinks it's a good time save its' state and calls the server methods -> Save() method is called -> Save calls async method in playerservices -> this does it's magic -> this returns to save -> Model sees a that save was success and continues to do its' business.

Answer 1

Now how do I wait for that task to run to the end before it returns to the method Save()?

In this case, you can Wait the Task returned by Task.Run . This is not an optimal solution (it's a hack), but you can't have an optimal solution unless Unity supports await .

Also do this without blocking the thread?

That's not possible. You're exposing a synchronous method to Unity, and when a synchronous method returns, it's complete. So you have to either block the thread or return after starting an asynchronous operation (like your code is already doing).

Also there is the problem of synchronization context, it seems that when calling the initial call through SignalR it doesn't like if the context changes.

SignalR 1.x had some quirks around SynchronizationContext . SignalR 2.0 was just released (and they were supposed to fix those quirks in that release); I'd try upgrading and see if it works better.