RE: [PowerThreading] Where do you see AsyncEnumurator in regards to the Async CTP announced today?
I has very heavily involved with the creation of the new Async features that Microsoft has added to the next version of C#/VB.
We had monthly meetings that lasted well over a year and the survey that I asked members of this group to take several months ago directly affected the final implementation.
In essence, the new async feature in the language is just like the C# iterator feature except that the await keyword is used in place of ‘yield return’. The new keyword feels more natural and it can be used in an expression context as opposed to a statement content which simplifies your code allowing it to be more composable. Also, async methods can invoke other async methods which is a huge improvement over what iterators allowed you to do. This allows you to have async subroutines which you can call from other async (or non-async) methods which also allows for composition. My AsyncEnumerator also supports this but it is much more clumsy to do.
The new async feature centers on Task which offers three big benefits. First, it is just easier than using Begin/End/IAsyncResult. Second, if unifies performing compute-bound and I/O-bound operations around a single construct. Three, it integrates the SynchronizationContext into it which is another big improvement over Begin/End. All of this yields a lower concept count for programmers and things work more naturally. Also, I don’t know if MS will officially obsolete or deprecate the event-based APM (like BackgroundWork and WebClient classes) but they definitely should discourage people from using classes that follow the event-based pattern. This pattern has always had many problems with it and I feel strongly that it should have never been produced in the first place. The new async stuff is much better than what the event-based pattern has to offer.
As for AsyncEnumerator:
· It runs on .NET 2.0 and above. The new async stuff will not work on these platforms; in fact it isn’t even shipping yet.
· I need to look into the details more but I’m pretty sure that the new async stuff has a slightly higher overhead than using my AsyncEnumerator. With the new stuff, you create a Task (an object that has many fields in it) and this will wrap the Begin/End that exist in the framework today. So you end up allocating more memory and executing calls to calls. For people who are really memory/perf conscience, I’m pretty sure that my AsyncEnumerator uses less memory and runs faster; I haven’t done the research to give any exact numbers on this however.
· My AsyncEnumerator still offers some features that the new async stuff doesn’t. For example, the debugging support in the AsyncEnumerator is far superior to what the new async stuff offers. My AE also gives you a way to hook the state machine suspend/resume events which some of my customers have needed to migrate state from thread to thread as the state machine continues execution via different thread. I also offer a way to opt-out of using the SynchronizationContext so that some work can be performed on a GUI thread and some work on a worker thread. The async stuff always using the SynchronizationContext. Finally, for some scenarios, the coding is a little simpler with my AE. For example, with my AE, you can easily wait on ‘n’ operations to complete which with the new async C# stuff, you have to use combinator methods.
I love the new async .NET stuff and it was definitely the right thing for the team to do. Remember that it is in its infancy right now and that the team will add better debugging and other features as time goes on. My AsyncEnumerator will continue to be available for those that need .NET 2.0 or later support and I will keep it working with new versions of C#/.NET so that people are not forced to port their code over to the new model. I may try to enhance the new async model with better debugging features and other things that AE currently offers which the new model does not offer today. I feel that I have been very responsive to AsyncEnumerator users and I intend to continue to do that. I can certainly be more responsive than Microsoft can and can deliver features or bug fixes more quickly,
Personally, I am very proud that my AsyncEnumerator and its success played such a huge part in the industry and that I was able to assist Microsoft in producing the new async features. My goal has always been to try to make it easy for others to build scalable and responsive applications and components and I feel that I am playing a big part in this which is very rewarding.
--Jeffrey Richter (http://Wintellect.com)
Now that the Async CTP has been announced and described do you see it as complimenting, replacing or just as an alternative to AsyncEnumerator?
Will the CTP affect the future of AsyncEnumator?