Tasks and the APM Pattern

re: Tasks and the APM Pattern

Stephen Toub - MSFT — Mon, 08 Aug 2011 19:15:50 GMT

Thanks for the doc suggestion, Fritz.

re: Tasks and the APM Pattern

Fritz — Mon, 08 Aug 2011 17:10:05 GMT

What the documentation never states is that FromAsync will also throw whatever exception the BeginOperation method that is passed as an argument might throw. E.g. if you are passing as an argument a .Net APM operation that creates a network connection and the endpoint is not found you will get an exception right then and there when you call the FromAsync method and the task will not be created. This would merit a mention somewhere on msdn, but I couldn't find anything.

I was trying to catch exceptions and return a faulted task (so that I only have to do error handling in one place) but that doesn't work:

Task<Stream> requestTask = Task<Stream>.Factory.FromAsync(

(stream, callback, state) =>

{

try

{

return serviceProxy.BeginRequest(stream, callback, state);

}

catch (Exception ex) // e.g. CommunicationException when endpoint can't be reached

{

TaskCompletionSource<Stream> tcs = new TaskCompletionSource<Stream>();

tcs.SetException(ex);

return tcs.Task;

}

(asyncResult) =>

{

return serviceProxy.EndRequest(asyncResult);

}, ...);

The task returned in the case of an exception from BeginRequest is Waiting for Activation, not faulted. It looks like I have to wrap the call to FromAsync in a try/catch block. Any ideas?

Tasks and the Event-based Asynchronous Pattern

Parallel Programming with .NET — Fri, 19 Jun 2009 21:43:13 GMT

As has been discussed previously, one of the new features in the Task Parallel Library is TaskCompletionSource<TResult>

re: Tasks and the APM Pattern

Stephen Toub - MSFT — Thu, 18 Jun 2009 02:36:26 GMT

Thanks for your thoughts on this, James.

re: Tasks and the APM Pattern

James B — Wed, 17 Jun 2009 19:55:31 GMT

Scenarios... Hmm. Sure thing. Suppose you have a server with some methods that can return from immediately, and some that require file access, database access, etc.

Now, in Twisted Python, there's a function called defer.maybeDeferred that will take a normal value or a Deferred (essentially a Future<T> in your case), and if it's a normal value call defer.succeed on the value to make it a Deferred. Since .NET is strongly typed this is not necessary. Instead the server would pass back a Future<T>.

Then, the method calling the server's request function will receive the Future<T> back, and attach callbacks that take in the response and encode it. The encoder returns a Future<T>. The I/O level then attaches callbacks to send it to the other side. Each level modifies the return value.

Anyway, what the .succeed/.fail feature does is allow this whole process, in the event that there's nothing to wait on, to occur without any switching or scheduling at all. .callback (.NET .ContinueWith) would execute immediately, since the Future<T> returned is already finished. This is a rather common case.

And yeah, right now I have it inside a FutureHelper I wrote (using the CTP, there is no Factory, so nowhere to put an extension method).

By the way, have you considered talking to the CLR team? They need to make it possible to use T as void in generics. This would save you an enormous amount of duplication, and could be implemented as an empty struct plus optimizations (i.e. return a; -> return; if a is void, b = a -> no op if b and a are void, etc.). The Action/Func duality is entirely an artifact of this lack, and it's propagating into your API as well. Just a thought :)

re: Tasks and the APM Pattern

Stephen Toub - MSFT — Wed, 17 Jun 2009 19:26:15 GMT

Hi James-

Thanks for the suggestion. We've considered adding such a helper, e.g. Task.Factory.FromResult(value) and Task.Factory.FromException(exc), and may do so at some point in the future. Could you elaborate on the scenarios where this would be useful to you?

You can also write these yourself as extension methods (in fact, you'll find such extension methods in the Beta 1 samples at http://code.msdn.microsoft.com/ParExtSamples), e.g.

public static Task<TResult> FromResult<TResult>(this TaskFactory factory, TResult result)

{

var tcs = new TaskCompletionSource<TResult>();

tcs.SetResult(result);

return tcs.Task;

}

Thanks.

re: Tasks and the APM Pattern

James B — Wed, 17 Jun 2009 19:14:11 GMT

Hmm... in addition to Begin and End async methods, it might be nice if you added helpers for synchronous methods.

Twisted Python does something like this, and it's very handy. Oftentimes you have a method that could be asynchronous, but is synchronous in some instances. In those cases, you'd (with TPL) end up doing

var f = Future<blah>.Create();

f.Value = value;

return f;

It'd be nice if there were a helper, such that I could just return Future<blah>.Succeed(value); or in the case of setting Exception, Future<blah>.Fail(value);

Look at Twisted Python's Deferred for more inspiration. :)

Tasks and the APM Pattern | VishwaTech IT News

Tasks and the APM Pattern | VishwaTech IT News — Wed, 17 Jun 2009 15:21:20 GMT

PingBack from http://www.vishwatech.com/globalnews/?p=1714

re: Tasks and the APM Pattern

Stephen Toub - MSFT — Thu, 11 Jun 2009 17:32:14 GMT

Hi Olivier- Thank you for your feedback.

re: Tasks and the APM Pattern

StoneFactory — Thu, 11 Jun 2009 15:46:21 GMT

Hi Stephen,

First, I like self descriptive names and I really think FromAsync miss the already started aspect (Task.Wrap and Task.WrapAndStart or something like this should be better).

Second, I always separates object creation and execution start. It's not same stuff.

Third, I work on a StateMachine engine where state activities must be described during initialization of state machine. Tasks can be used to implement states activities but Start process must be done only on state entry during execution step (long away from initialization).

In fact, the initial problem is having your Task implements IAsyncResult. When you start a standard BeginXyz APC, you only get IAsyncResult implementation instance when process have already been started. IAsyncResult is a kind of token describing a currently running asynchronious execution. But Task can be started after construction. So, during time time between construction and Start, your Task is not an IAsyncResult.