Async='true' in ASP.NET 2.0

There's an intriguing new attribute on the Page directive in Beta 1 of ASP.NET 2.0 - Async. It maps onto the IsAsync property of the Page class and from what I can tell right now, does absolutely nothing :)

<%@ Page Language="C#" Async="true" %>

I wrote an article on building asynchronous handlers and pages a while back, and at the time I had some discussions with Erik Olson (a member of the ASP.NET team at Microsoft) and he mentioned that they might be adding an async property to pages in the next release. When I saw it today in the Beta 1 drop, I quickly threw a page together and ran it through the test harness I had built to research async handlers for the article. The results show absolutely no difference between standard pages and async pages in terms of freeing up threads to service other requests. A quick perusal through Reflector reveals that the IsAsync property is not referenced anywhere yet either, so obviously it's just a zygote at this point. I look forward to seeing the final implementation.

This also got me to thinking, it might actually be a good thing to leave the async property as it is. It's almost too tempting to just flip it on, especially since it shows up in the designer in VS.NET 2005. The current documentation simply states: This property determines whether the page is processed asynchonously or not. Doesn't it sound cool to have your pages processed asynchronously? I can imagine people thinking that making all of their pages asynchronous will make their server more efficient - heck, you could just go to your machine.config file and make the default for pages on that machine to be async. This of course would introduce a lot of extra request processing time with unnecessary thread switching and managing a secondary thread pool (depending on how they finally implement it). Pages are already processed asynchronously via the standard CLR thread pool in the worker process. Making a page asynchronous would presumably free up the request thread to service additional requests while this request completed its work on a thread from a secondary thread pool, which is only occasionally a good idea.

So here's my recommendation to the ASP.NET team - leave the async property as is in the 2.0 release bits, just a placebo for people to switch on and feel better about their applications. Under the covers, give us some way of programmatically making a page asynchronous without building our own thread pool - something tricky like providing a private implementation of an interface, so you know it will never happen by accident or by someone that doesn't understand the implication :) :)