I read some posts and articles on the internet saying that I should not use async until my calls are IO (reading file, sending request, etc.). But if the calling API is actually an IO-related API and does not support async calls, should I wrap them with `Task.Run()`?

Say, if I have MVC server calling an external server via API to get data, but the API does not have async methods. Is there a benefit wrapping sync calls with async in such case?

As I understand, if not wrapping, then all calls to the API are sync and each call to my MVC app uses a thread from thread pool. In second case `Task.Run()` will queue my task onto thread pool, but releases main thread. Is released main thread considered to be benefit here, or it is not worth wrapping? Am I correct here at all?

**EDIT**
Ok, here are some more details as people requested.

I have a third party .NET assembly that I'm forced to use. I can't just call the web-service directly. It looks pretty much like this: 

```cs
// the API (I not owner of it, can't change it):
public class Service {
  /* everything is synchronous like this. but somewhere inside
   it still makes HTTP requests to external server, so that's 
   kinda IO. just the lib is very old and doesn't provide async methods*/
  public Data GetData(Paramters parameters);
}

// here comes my code.
// option 1. sync controller
public class MyController {
  public ActionResult GetDataById(string id) {
     var data = new Service().GetData(new Parameters{Id = id});
     // process and return some result ...
  }
}

// option 2. async controller
public class MyController {
  public async ActionResult GetDataById(string id) {
     var result = await Task.Run(() => new Service().GetData(new Parameters{Id = id}));
     // process and return some result ...
  }
}

```

So the question is, does it make sense to do option 2?