Task.Wait() -Why??

Kevin Marois

See [this](https://msdn.microsoft.com/en-us/library/dd235635(v=vs.110).aspx) MSDN example If Task.Wait blocks, why would you ever want to use it?? If I'm in a WPF app and I launch a task from the main thread, it blocks the UI, so why bother using a thread? If I'm going to block the main thread, why not just put the thread's code in the UI to start with? Someone please give me a real example of when I would really want to use Task.Wait. Thanks

If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

Pete OHanlon

You are assuming here that the only time that you would want to use a Task is off the UI thread. This isn't the case. As an example, suppose you wrote some code to index files in a particular folder - and you then want to finish the task only once the indexing has completed, you could very well create a top level task and then fire off multiple tasks inside - with a Wait on them completing.

This space for rent

Kevin Marois

So, Task A spawns 3 child tasks, then waits for all 3 to finish. In this case you would want Task A to run async, correct?

If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

Pete OHanlon

Yes.

This space for rent

Richard Deeming

In that example, it would be better to use Task.WhenAll[^] to wait for the child tasks to complete.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Pete OHanlon

That's true. I was trying more to illustrate the point that waiting on a task or a series of tasks doesn't mean that you created it off a UI thread.

This space for rent

Richard Deeming

There are very few situations where it's necessary to block the current thread until a task has completed. The only obvious one that comes to mind is when you're writing a console application, and you want to use async code. And with .NET 4.5 or higher, it's usually better to call task.GetAwaiter().GetResult() rather than task.Wait(), to avoid having any exceptions wrapped in an AggregateException.

static class Program
{
static void Main()
{
MainAsync().GetAwaiter().GetResult();
}

static async Task MainAsync()
{
    ...
}

}

But in most cases, there's usually a better option than blocking the current thread.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Kevin Marois

Richard Deeming wrote:

There are very few situations where it's necessary to block the current thread until a task has completed.

That's why I asked. I can't see a reason to block, and the example I posted shows the Main method of a console app creating a thread that blocks. It's a typical stupid MSDN example, but I thought I'd ask anyhow. Thanks

If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

Richard Deeming

I guess it's difficult to produce a meaningful real-world example that doesn't end up with the concept you're trying to demonstrate buried in unrelated implementation details. :) You just need to imagine that the task is an async method, calling an API that's only available via asynchronous task-returning methods. The Main thread is synchronous, so you're going to have to block at some point to wait for the API calls to complete.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Tridip Bhattacharjee

this line

MainAsync().GetAwaiter().GetResult();

block the main thread. thanks

tbhattacharjee

Richard Deeming

Yes - which is exactly what I said in my message, if you'd bothered to read it. :doh:

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer