Native support for task { ... }

[dustinmoris]

I propose we implement a task {} workflow, similar to async {} which can execute and unwrap a Task, Task<'T> and ValueTask<'T> without having to convert the task into an async workflow first.

Given that most .NET libraries (almost everything if not everything) implements asynchronous methods which work with Task and Task<'T> it doesn't make sense to constantly have to convert back and forth between async workflows and tasks with the static Async.{...} methods if F# could just natively work with tasks instead.

My proposal is to add a task {} workflow which can exist side by side to the already existing async {} workflow. It would be a non-breaking addition to the F# language and probably (over time) supersede async {} altogether (I think async would only be used for backwards compatibility at some point).

Pros and Cons

The advantages of making this adjustment to F# would be better performance (as I understand that Tasks are slightly faster than Async and it will cut down the additional overhead cost of converting from Task to Async and from Async back to Task in every application. For example this is typical overhead in a standard .NET web application written in F#).

There are no disadvantages, because Async will still exist.

Extra information

FSharpX has a task computation expression and someone else has further improved it in this GitHub repository, which claims to be a lot faster.

Estimated cost (XS, S, M, L, XL, XXL):
S-M

Related suggestions:

• Provide an Async conversion function for structural awaiters

The difference between #559 and this suggestion is that I don't propose to add more conversions between Task and Async, but to add native support for Tasks instead.

Affidavit (must be submitted)

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• This is not a breaking change to the F# language design
• I would be willing to help implement and/or test this
• I or my company would be willing to help crowdfund F# Software Foundation members to work on this

[lambdakris]

Overall, I think it is a good idea for pragmatic purposes, but to be fair, there are some cons:

1. Having two different but similar ways of creating asynchronous computations would add some cognitive overhead (even now there are times when I am indecisive between using async or mailbox for certain parallelism/concurrency scenarios).
2. I am still getting a grasp of the issue, but I have seen it mentioned several times that Async composes better than Task and this would mean that they cannot be considered completely interchangeable (though I am unsure if this is inherent to Task or if it could be resolved by proper design of a task ce)

Nonetheless, I do agree that it would make it more approachable to work with the majority of .NET libraries and it certainly is an issue that gets raised every so often with regards to good F# support in this or that library/framework. In particular, I remember that there was an Orleans issue about this very thing and while that particular issue never got resolved it was addressed in Orleankka by implementing a custom task ce. So I would say that if authors of both ASP.NET and Orleans based F# libraries have found a need for a task ce, it might make sense to make it official.

[rmunn]

One of the most important differences between Async and Task, and this would need to be well documented in the docs for the task CE, is that when you run a function that returns an Async, the Async has not started yet. Whereas by the time you're holding a Task object, the Task is already running. That is why Asyncs compose better than Tasks, and why even if we do add a task computation expression, we won't want to get rid of async. See http://tomasp.net/blog/async-csharp-differences.aspx/ for more details.

[matthid]

@rmunn I don't want to confuse anyone here. But that is just how the C# compiler is doing it. You actually can have a "not-started" task object (and start it with the "Start" method). I have actually used that in the past. But I agree that the general philosophy is that Tasks are already running, while Asyncs are not.

Starting Tasks manually is incredible painful and error prone.

[ReedCopsey]

An alternative to this suggestion might be to just ease the interop between async and task. FusionTasks is an example of an approach to this, and I'd love to see something similar baked into the async builders and support in F#.

[dustinmoris]

@ReedCopsey One motivation of this proposal is to cut down overhead as well where it is not required. FusionTaks is nice, but it still has to convert between the two models where there are many cases where an application could live entirely without a single conversion if there would be native support for tasks.

[ReedCopsey]

A true implementation to handle Task and ValueTask probably should, ideally, use the functionality from C#'s task like types.

However, I expect that'd change the scope of work from S-M to more L+...

[buybackoff]

As my experiments are linked here, a small clarification:

FSharpX has a task computation expression and someone else has further improved it in this GitHub repository, which claims to be a lot faster.

Not my rewrite but the Task CE from FSharpX is a lot faster than crossing async <-> TPL boundary. The rewrite just eliminates one allocation, its perf difference is not clear.

Using a single let! from that CE is quite fast and convenient and is on par with using awaiters with OnCompleted callbacks manually (this is what the CE does inside, but the task{} syntax is very nice). Loops are the problematic thing - while and for from the CE generate so much overheads and garbage that they become unusable on hot paths. I tried to rewrite it in many different ways, but could't reduce that. Every iteration of a loop goes through several methods of CE machinery - and this is the pain point where native task{} implementation could be very helpful. A gotcha was to use recursive functions with simple let! instead of loops in CEs. Maybe someone more experienced with CEs could just rewrite the task builder in more efficient way using awaiters and callbacks.

[0x53A]

One thing I would like to call out is to NOT repeat the mistake of C# with regard to context capture.

To ease working with Tasks in a GUI context, they enabled capture by default, which means that in a non-gui context you need to add .ConfigureAwait(false) everywhere.

I've been using TaskBuilder.fs (https://github.com/rspeele/TaskBuilder.fs) in a few projects, and it works quite well.

And the best feature is that it acually has two taskbuilders, ContextSensitive, which behaves like C#, and ContextInsensitive, which does not capture the context.

So I am all for adding a native optimized task CE to F#, but please take care of the context handling.

[gerardtoconnor]

I think having an inbuilt task CE is essential for easy .Net Library Interop without a performance hit on conversions back and forth to async, but I think the async and task would perform two different functions.
@dustinmoris

and probably (over time) supersede async {} altogether

The starting and running of async work pipelines with Async is safer and easier so I think Async still serves a purpose although if the two could someday converge it would simplify things ... have a f# Task module that safely started/managed/parallelised task workloads the way Async does today.

@lambdakris

Having two different but similar ways of creating asynchronous computations would add some cognitive overhead (even now there are times when I am indecisive between using async or mailbox for certain parallelism/concurrency scenarios).

@rmunn

when you run a function that returns an Async, the Async has not started yet.

If it is clear that task CE is a helper CE for .net application/librarys that predominantly manage the starting of their own tasks, task CE would just be an async function pipeline, while Async in its own right can manage the whole pipeline of starting, parrallel, async etc. The task CE would not have any parallelism built in (for/while in Async CE are not parallel). This narrows the use case down to working with .net libraries where no Async is needed as library manages task lifecycle. I agree that task CE is not a substitute for extensive functionality Async, would have a specific use case of .net task library interop without the expensive conversions back and forth to Async that are unneeded.

@ReedCopsey

A true implementation to handle Task and ValueTask probably should, ideally, use the functionality from C#'s task like types.

Would that be needed for just a task CE or to impliment a Task Module with comparable fucntionality to Async? If the later, I do agree it would be a big job. If the former, just the task CE, you will know better then me but CE overloads & type inference is a bit limiting now, when trying to overload task CE with plain Task as well as standard Task<'T>, the compiler complains that some bindings need type annotaitons as types cannot be inferred. if the CE bind was an inline function and not a class method overload, we could put type constraint on the bind type ('T when 'T : (member GetAwaiter : unit -> Awaiter<'U>)), but if we are focusing on CE, I dont know if we can improve type inference from type constraints as CE uses method overloads and not inline function ... if there is a way, I would greatly appreciate some direction?

@0x53A
Agreed but I think perhaps we make the default simple task CE ContextInsensitive as if people want to handle parrallel compute on shared state/data, they should be using alternaive mechanism unless GUI. One of the motivations for introducing a task CE would be for easy interop with ASP.NET core and it should be noted, there is no sync context in ASP.NET core, they did away with it for obvious performance reasons and the lack of GUI requirements etc, I would focus on just the insensitive one now and then perhaps introduce additional synctask {} after if GUI (etc) people want it?

@buybackoff

Maybe someone more experienced with CEs could just rewrite the task builder in more efficient way using awaiters and callbacks.

This is very helpful for team building it to know ahead of time, if for and while loop can perhaps use lightweight recursive task unwrapping or somehow reuse task completion source, would help reduce overhead you identified.

[gerardtoconnor]

Ideally, if we could bind based on the member GetAwaiter() we could do something like below (and use on Task<'T>, ValueTask<'T> and any other awaiter) but I get a compliler error saying :

could not be generalised because it would escape scope

   // General Task type case that can accept Task<'T>, ValueTask<'T> and any other custom awaiter type 
   member this.Bind<'T,'S,'U when 'T : (member GetAwaiter : unit -> TaskAwaiter<'S>)>(m:'T, f:'S->Task<'U>) : Task<'U> =
      let a = m.GetAwaiter()
      if a.IsCompleted then a.GetResult() |> f
      else
            let tcs = TaskCompletionSource<Task<'U>>()
            let t = tcs.Task 
            a.Completed(fun () -> tcs.SetResult( a.GetResult() |> f ))
            t.Unwrap()

[isaacabraham]

@matthid but aren't the majority of Task-returning methods in the BCL "hot" tasks? In which case it would be pretty difficult to reason about what "kind" of a task you already have. In this respect Async is very consistent.

[dustinmoris]

This is true, what many already pointed out, Task cannot replace Async in F#, because having the control of when an async computation gets started makes more sense in a functional language. The Task support would have to be an addition to better interop with other .NET code.

[Tarmil]

One of the most important differences between Async and Task, and this would need to be well documented in the docs for the task CE, is that when you run a function that returns an Async, the Async has not started yet. Whereas by the time you're holding a Task object, the Task is already running.

Not only has the Async not started yet, but you may never start it, or start it multiple times. Conceptually Async<'T> is isomorphic to unit -> Task<'T>.