Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Benefit of returning Task<T>? #406

Closed
Zyphrax opened this Issue · 8 comments

3 participants

Zyphrax David Fowler Christoph Burgdorf
Zyphrax

In some of the samples I see that you return a Task.
The client - server communication seems already asynchronous.

What is the benefit of doing this?

David Fowler
Owner

Instead of using what? A callback?

Zyphrax

Let's say I'm doing:
1. Connect to hub
2. Call hub method Test
3. Test returns an integer

Step 2 is already asynchronous, it specifies a javascript callback that will be called when the method Test is complete. What is the benefit of making Test return a Task[int] instead of a direct int?

David Fowler
Owner

I'm confused about which part of the asynchrony you're talking about. The bug makes it seem like you're confused about client side calls but now it seems like you're talking purely about the server side.

Just because the http request is async doesn't mean you're doing non blocking work. If you do an expensive cpu bound operation then return a number, that blocks the request and it's not a great use of async. If you make an async IO bound call however, you'll see the benefits.

This might help explain some of the general benefits of async:
http://msdn.microsoft.com/en-us/library/ee728598.aspx

Zyphrax

This is not really a bug, more a question.

Thank you for the link.

I thought that the SignalR requests were already asynchronous.

If I understand correctly if I have a request that takes 5 seconds to return a result, the server won't be handling any other SignalR requests until it has completed the first request. Unless I make it asynchronous.

David Fowler
Owner

@Zyphrax That's not correct at all. SignalR requests are all async, my point is you may not be taking advantage of the asynchrony. This might make it clearer:

What's the difference between:

public Task<string> SearchAsync(string q)
{
    return MyWebRequestAsync("www.google.com?q=" + q);
}
public string Search(string q) 
{
    return MyWebRequestSync("www.google.com?q=" + q);
}

The former takes advantage of async since it's an IO bound operation (making a webrequest) and will scale better if you're making lots of them. The sync call (even though the request is async) will block a threadpool thread and will scale much worse overall.

Here's a great quote from Brad Wilson's blog on async server programming:

In addition, there’s no point in making a task on the server when what you’re doing is fundamentally CPU-bound. There’s no background thread for this work to hide on, so all you’re doing is incurring an expensive thread switch. Where TPL makes sense on servers is when you’re consuming something which is fundamentally async but not CPU bound, which means things like database operations and web service calls.

http://bradwilson.typepad.com/blog/2012/04/tpl-and-servers-pt1.html

Zyphrax

Ah ok, that makes sense.

I was looking into it with regard to database queries. I just found this link:
http://blogs.msdn.com/b/rickandy/archive/2009/11/14/should-my-database-calls-be-asynchronous.aspx

Thank you for the explanation.

Zyphrax Zyphrax closed this
Christoph Burgdorf

"In some of the samples I see that you return a Task.
The client - server communication seems already asynchronous.

What is the benefit of doing this?"

I think I see where you are struggeling, maybe I can help you a little further.

You have two different levels of asynchronity in the whole process. The first effect of asynchronity happens on the browser level. Let's say you use the jquery $.ajax, $.post or $.get methods (just let's use jquery as an example here) to run a severside method that produces a return value (this is absolutely SignalR agnostic). From a javascript standpoint this happens already async. But the serverside code may still be totally sync as with in @davidfowl example:

public string Search(string q) 
{
    return MyWebRequestSync("www.google.com?q=" + q);
}

What makes it appear async to your javascript world is actually the browser that kicks of the process, gives the control back to you and then calls back when the results are ready. But that still means that the serverside processing is NOT async and that means that it blocks a serverside thread.

So you really need to get this right: There are two levels where async happens. And the places you found that you wondered about are all about serverside async processing and not about clientside async processing. Hope that helps ;-)

Zyphrax

Thank you for the extra information cburgdorf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.