Ayende @ Rahien

Whut commented on TPL: Composing tasks

Mon, 22 Nov 2010 10:11:31 GMT

I'm definitely missing something, but why don't you just put CreateServerConnection and HandShakeWithServer inside one task?

David Hanson commented on TPL: Composing tasks

Fri, 19 Nov 2010 06:19:14 GMT

I "Subscribe" ;-) to the Rx approach. We use the approach outlined by Omar to load data from mutliple domains services in Ria and works very well.

Jonas commented on TPL: Composing tasks

Wed, 17 Nov 2010 07:16:41 GMT

Use a TaskCompletionSource and set up your method to return you tc.Task and then wrap your async methods neatly to call tc.TrySetException | TrySetResult when they complete.. Tada...

Jeff Cyr commented on TPL: Composing tasks

Tue, 16 Nov 2010 23:24:18 GMT

@jesus Note that you can prevent the application crash by subscribing to TaskScheduler.UnobservedTaskException: TaskScheduler.UnobservedTaskException += (sender, e) => { Console.WriteLine(e.Exception.ToString()); e.SetObserved(); };

Dan Jasek commented on TPL: Composing tasks

Tue, 16 Nov 2010 20:30:38 GMT

I think Omer has the best solution. I have been underwhelmed by the implementation of Task. Cold tasks are basically useless, they forgot to make an ITask... And now Jesus' exception handling issue. RX doesn't have any of these problems, including the need to unwrap. It is just better thought out. I hope they add some sort of iterative await for RX before they release 5.0.

Omer Mor commented on TPL: Composing tasks

Tue, 16 Nov 2010 19:05:40 GMT

If you'd go the Rx path, composition is trivial: Task CreateServerConnectionAsync() { return (from sc in ServerConnection.CreateServerConnectionAsync().ToObservable() select sc.HandShakeWithServerAsync()).Single(); } Instead of a Task, you can return an observable of unit (sort of void), and have more native Rx signature: IObservable

Jesús López commented on TPL: Composing tasks

Tue, 16 Nov 2010 09:47:35 GMT

I forgot to include Console.ReadLine after Console.WriteLine. Anyway, it crashes

Ayende Rahien commented on TPL: Composing tasks

Tue, 16 Nov 2010 09:43:53 GMT

Jesus, Thanks. The actual exception is very informative: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. Which makes total sense.

Jesús López commented on TPL: Composing tasks

Tue, 16 Nov 2010 09:35:54 GMT

Yes it will. Try this code and see how the console application crashes: static void Main(string[] args) { try { var t = GetComposedTask(); Thread.Sleep(1000); t.Wait(); GC.Collect(); GC.WaitForPendingFinalizers(); Console.WriteLine("Press enter"); } catch (Exception ex) { Console.WriteLine("Caugth exception {0}", ex.Message); } } static Task GetComposedTask() { return Task.Factory.StartNew(() => { throw new Exception("Some error ocurred"); }) .ContinueWith( _ => { Console.WriteLine("Hello from task"); }); }

Ayende Rahien commented on TPL: Composing tasks

Tue, 16 Nov 2010 09:11:25 GMT

Jesus, What are you talking about? Exceptions inside tasks will not kill the app domain

Jesús López commented on TPL: Composing tasks

Tue, 16 Nov 2010 09:05:19 GMT

However there is a subtle problem. If CreateServerConnection fails you will end up with an unobserved exception which will cause the entire app domain to crash if you don't catch unobserved exception in your app domain. I use the following task extensions for composing tasks and observe antecedents: public static Task continuationFunction, TaskContinuationOptions continuationOptions) { return task.ContinueWith(t => { if (t.Status == TaskStatus.Faulted) { throw t.Exception; } return continuationFunction(t); }, continuationOptions); } >

Ayende Rahien commented on TPL: Composing tasks

Tue, 16 Nov 2010 08:20:38 GMT

KAE, Damn it! I was sure that I had such an elegant solution, and then you come up with this beauty. Thanks!