Returning from a task without blocking UI thread

I agree that using async/await is the best approach here. As noted, when you await an async method, then even though the declared return type is a Task<T>, the compiler translates this into an implicit return type of T.

The gotcha is that all async methods must return void, Task, or Task<T>. So once you start using them, you have to “bubble up” the “async” method attribute until you get to a point where you can either block on the result or your method can be void or Task (i.e. you’ve consumed the actual result).

Please see this simple UI-based example:

/// <summary>
/// Interaction logic for MainWindow.xaml
/// </summary>
public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
    }

    private async void Button_Click(object sender, RoutedEventArgs e)
    {
        statusText.Text = "Running";
        statusText.Text = await _ComputeText(true);
        statusText.Text = await _ComputeText(false);
    }

    private static async Task<string> _ComputeText(bool initialTask)
    {
        string result = await Task.Run(() =>
            {
                Thread.Sleep(2000);
                return initialTask ? "Task is done!" : "Idle";
            });

        return result;
    }
}

Note that the button event handler, “Button_Click”, is simply declared as “void” return. But I can do that because I consume the asynchronous result in that method.

In your case, the returned DataTable is not available until the asynchronous task has completed. So you have to declare each method as “async” all the way back to whatever method is actually doing to do something with the DataTable. Even there, the method will need to be declared as async, but you won’t be returning the DataTable, and so that method can have a return type of “void” or “Task”. A common scenario is for this method to be a UI event handler, so “void” should be fine there (and will be required for use in an event handler delegate); your code isn’t calling it anyway. But it’s technically more correct to use “Task” instead, so if in your context that works, you should do it that way instead.

Without a concise-but-complete example, it’s hard to offer anything more specific than that.