C#: Async Callback - Does the callback method's processing block the application?

Basically, if I call an async method my application doesn't hang,开发者_C百科 I can click things and the such (if I allow it) without penalty. Once the async operation is complete, the callback method is executed.

I'm wondering if this blocks things again or is it still "asynchronous"? That is... say the callback method is extremely intensive, will my application still run nicely or is it blocked once the callback method is entered?

Update:

What I'm talking about are the methods created when you add a service reference and select "Async operations"

public void AsyncSaveFooCompleted(Object sender, SaveFooEventArgs e)
{
    //Send a large binary from the WCF Service
    Client.SaveFooBinary(Foo.LargeBinary);
}

public void SaveFoo(Foo foo)
{
    Client.SaveFooAsync(foo);
}

You will have some kind of blocking if your callback is that intensive. If you are having this issue, move more of the processing in the async method and leave the callback nice and simple.

Alternatively, if you need to process this in stages, have the callback start another async process with a different callback.

The callback method should not be intensive. In my opinion your thread should handle its intensive processing and let to the callback just the rendering logic.

I'm assuming you're talking about C# 5 async methods...

The callback will execute on the UI thread by default. It sounds like you should put the expensive work into its own task (e.g. with TaskEx.Run), then await that... assuming the heavy processing doesn't have to execute on the UI thread. If you've fundamentally got a lot of work which has to be on the UI thread, there's not a great deal you can do about that.

Your question is kind of vague, because you don't explain how you are performing the async operation. If you are using the new async methods in C# 5.0 like Jon Skeet suggested, then follow his advice, but if not then the easiest way for you to test (however you are doing your async), is to throw some blocking code in the callback.

Something along the lines of Thread.Sleep(10000), and you will know in an instant whether your callback will block the UI thread or not. In all fairness though, your UI thread should never have "intensive" work unless the user cannot continue or do anything until the operation is complete because of some requirement of that task, then it doesn't really matter because the user has to wait in either circumstance. However, you could still consider this bad design because any UI with intensive work on the UI thread gets the infamous "Not Responding" and the user may thing your app has stopped working, even though its still executing the task.