Async='true' take 2

I've not looked into ASP.NET 2 much yet so I might be completely wrong here... But is it possible that they might be looking to support the ability to do some async work in your codebehind before it goes on to generate the page?

On a few pages I've ended up with .aspx pages which have a certain amount of preprocessing work that could have been done asynchronously without necessarily tieing up any threads at all. E.g. if you're sending some message over a socket and must wait for a response, before you're ready to generate the page, then there's no need to tie up threads in the first phase. You could just to a BeginSend and BeginReceive on the socket, and use callback functions to handle the completion.

If you're writing your handler entirely from scratch, you could then use this to make your handler completely async - once the results are back in, generate the page content and complete the request. But there's no straightforward way of doing this today, as far as I know.

So what I'm thinking is some kind of approach where ASP.NET calls your AsyncBeginPageProcessRequest, and in here you fire off a bunch of intrinsically async (non-thread-consuming) operations. When the completion functions call you back, you then complete the request (i.e. your code calls the AsyncCallback that ASP.NET supplied you with) and ASP.NET will then carry on with the normal processing of the page.

This would avoid the common situation today of having a load of threads from the thread pool tied up in the early stages of .aspx handling - the part where you collect the data you require to populate the page.

Interesting idea, Ian, but I'm pretty sure this is just a default implementation of the IHttpAsyncHandler interface where AsyncBeginPageProcessRequest is a helper function to implement the interface. I presume they will just spawn off a new thread (or draw a new one from a pool) in the final implementation of BeginProcessRequest to immediately release the request thread and do work on a separate pool.
BTW - comments are a nice feature in a blog, don't you think? :) :)

I had a chat with Ian on IM, and he clarified his thinking. Because the BeginProcessRequest method was marked as 'virtual' he thought it might be possible to override it in a derived class, perform asyncIO work and then chain to the base class when you were ready. This would be a nice way of leveraging the async implementation, but since the virtual method is defined in the generated page-derived class, you can't derive from it! In 2.0 you will typically be using 'compilewith' which uses partial classes, and of course you cannot override a virtual method in the same class. Even if you resort to the 'classic' code-behind model, the generated class derives from you - not the other way around, so there is no way of using the 'virtualness' of the method in this case (in fact, one has to question why it is marked virtual at all).

Just one more update, in case anyone is actually reading this :) Ian found an example in the docs (look at the help for BeginEventHandler delegate) that shows an intended usage of async='true' combined with a call to AddOnPreRenderCompleteAsync that looks like a nice solution to performing non-cpu bound work in a web page without tying up a request thread. I'll try this out in my test environment and post one more blog entry on the results. Perhaps this is the intended usage of the async attribute, and if so, it looks promising!

See MSDN http://msdn.microsoft.com/msdnmag/issues/06/07/ExtremeASPNET/default.aspx