Task.Wait() -Why??
-
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.
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
-
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
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.
-
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.
Yes.
This space for rent
-
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
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
-
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
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
-
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.
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
asynccode. And with .NET 4.5 or higher, it's usually better to calltask.GetAwaiter().GetResult()rather thantask.Wait(), to avoid having any exceptions wrapped in anAggregateException.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
-
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
asynccode. And with .NET 4.5 or higher, it's usually better to calltask.GetAwaiter().GetResult()rather thantask.Wait(), to avoid having any exceptions wrapped in anAggregateException.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
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 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.
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
asyncmethod, calling an API that's only available via asynchronous task-returning methods. TheMainthread 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
-
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
asynccode. And with .NET 4.5 or higher, it's usually better to calltask.GetAwaiter().GetResult()rather thantask.Wait(), to avoid having any exceptions wrapped in anAggregateException.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
this line
MainAsync().GetAwaiter().GetResult();
block the main thread. thanks
tbhattacharjee
-
this line
MainAsync().GetAwaiter().GetResult();
block the main thread. thanks
tbhattacharjee
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
