Question on ContextInsensitive tasks

[dsyme]

Hi all,

A question for people who use TaskBuilder, in relation to https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1097-task-builder.md

As everyone might know, the proposed support for tasks in F# is very much based around the functionality of TaskBuilder and we started with the test suite (though the implementation is entirely new).

Now TaskBuilder supports ContextInsensitive tasks where ConfigureAwait is false by default, e.g. https://github.com/rspeele/TaskBuilder.fs/blob/master/TaskBuilder.fs#L352. However the task { ... } support in the F# RFC doens't include ContextInsensitive tasks.

So the question is - how important is it for inbuilt F# task support to support a builder (e.g. open ContextInsensitive ... task { ...}) for context insensitive tasks? Or is it ok for people to do this manually?

Personally I think moving away from the UI thread should be done explicitly, e.g.

task {
    do! Task.SwitchToBackgroundThread() // or whatever

    ... } 

or via explicit ConfigureAwait calls.

[0x53A]

I use ContextInsensitive and would appreciate it also being in the built-in version.

There are two related but slightly different use-cases for ConfigureAwait (false):

1. move from UI Thread to ThreadPool to unblock the user interface: I agree that this should better be explicit
2. your work is not thread sensitive, and you don't care whether it continues on the ThreadPool

In both cases you should add ConfigureAwait (false). Ideally to every await call, but at least to the first one per CE.

---

If you write a lib component, the behavior can also depend on the host. E.g., in a WPF application you have a synchronization context, in a console app you do not.

Omitting ConfigureAwait (false) can mean that your component runs fine in a console app, but deadlocks in a WPF app.

---

I'd go so far and say that outside of UI code, ConfigureAwait (false) should actually be the default.

Therefore, it should be as easy and as painless to do the correct thing as possible.

[dsyme]

Omitting ConfigureAwait (false) can mean that your component runs fine in a console app, but deadlocks in a WPF app.

I get your point, though the dual is also true - adding it may mean utility code doesn't stay UI-affinitized when the user expects it to ...

Anyway the default is ConfigureAwait(true) for better or worse, as it is in both C# task code and F# async.

...ConfigureAwait (false) should actually be the default.

The problem is that people are coming to tasks either from C# task code or F# async. Some use TaskBuilder.fs but only a few.

1. C# makes it explicit, so people basing their expectations on C# samples will add it anyway

2. F# async uses explicit indicators like do! SwitchToThreadPool() , also StartImmediate v Start etc. (which should have been called StartInThreadPool, and Parallel should have been ParallelInThreadPool)

I'm loathe to add a third different way of indicating context sensitivity at the level of an entire "open" statement right across a module. Either we should do it like C# does, or do it like F# async does, or let people make their own choice outside of FSharp.Core.

[dsyme]

@0x53A thanks for taking the time to reply. I'd love to have more data points. Can you link your code?

[rspeele]

I don't personally have to use ConfigureAwait very often in my day-to-day coding. When I use TaskBuilder I just open the default module.

However, my thinking when I added the ContextInsensitive builder was that people who do use ConfigureAwait(false), want to use it universally. Within a single async method if one awaited task is ConfigureAwait(false) and another is not, that's almost definitely a mistake, not intentional. And this typically extends to the whole source file or even whole project: either the code you're writing in that file is library stuff that doesn't care about synchronization context, or it's application stuff that does.

I figured it was pretty harmless to have it as an option, especially with the context-sensitive one being the autoopened default to avoid surprises for devs coming from C# async methods (I definitely believe that all our defaults should match C# behavior for sanity's sake even if they aren't the "best" defaults). And to be frank, I have such a soft spot for neat tricks with inline functions, I thought it was pretty cool that the compiler would pick the ".ConfigureAwait(false)" inline binds for tasklikes that support that method, but still smoothly fall back to the regular bind for tasklikes that don't.

The existence of things like Roslyn analyzers and Fody plugins that add ConfigureAwait(false) to everything suggests that this is something that at least a handful of C# developers are frustrated by and want a catch-all solution to.

Whether that is worth the testing, complexity, and maintenance costs for an F# built-in, I don't know.

[0x53A]

Can you link your code?

I'm currently using it only with Giraffe, and as far as I know, it doesn't actually matter there, because asp.net core doesn't have a synchronization context. I'm still using the ContextInsensitive builder because I wasn't 100% sure, and it makes it more explicit.

In my current job I'm not using F# with a GUI app.

---

...ConfigureAwait (false) should actually be the default.

This was more of a moral statement than a technical statement. If you are a library developer, and you write a component that does not require the synchronization context, you should always use ConfigureAwait (false). There are lengthy discussions about this on github and/or reddit, and the main argument against is that it clutters up the code. Which is why it should be as easy and "clean" as possible to do the correct thing.

And as rspeele mentioned, you either need it, or you don't; in most cases this is a binary choice and should be consistent for all awaits in the same method/file/project.

I get your point, though the dual is also true - adding it may mean utility code doesn't stay UI-affinitized when the user expects it to

I don't think this is an issue in most cases, the ConfigureAwait (false) only affects the remainder of the current method (in c#) / current CE (in f#), but NOT anything up the callchain.

For example (I hope this is correct, my C# async is a bit rusty):

async Task Parent()
{
    // UI Thread
    await Child()
    // switched to UI Thread again after Child()
}

async Task Child()
{
    // UI Thread
    await Task.Delay(100).ConfigureAwait(false);
    // ThreadPool
}

---

The need for this is there, for example there are a bunch of proposals on https://github.com/dotnet/csharplang asking for this exact thing: dotnet/csharplang#2542

---

As one additional anecdote, I was using Akka.Net from a WPF application and got deadlocks. Apparently it was previously only used in web/console apps and no one noticed this before me. This was fixed by sprinkling CA(f) everywhere inside Akka

[dsyme]

The need for this is there, for example there are a bunch of proposals on https://github.com/dotnet/csharplang asking for this exact thing: dotnet/csharplang#2542

Yes indeed! Thanks for this link :-)

[dsyme]

F# has a few obscure open-able modules that very fe people end up using. Does anyone really do

open Checked

or

open NullableOperators

or

open NonStructuralComparison

? I think these are barely known, especially the last

Am I write in thinking that a ContextInsensitive builder could be defined from the outside, in terms of a default ContextSensitive one in FSharp.Core?

[baronfel]

One thing to check out here is the behavior with regards to AsyncLocals/ThreadLocals in the different modes, specifically that the new rewrite mechanism respects execution context capture and restore per @NinoFloris's comment here.

[NinoFloris]

For task all of this will happen properly if all user code runs in IAsyncStateMachine.MoveNext as AsyncMethodBuilder.Start does the appropriate set & reset dance here https://github.com/dotnet/runtime/blob/9a905533d739564c14306ba3349fd7f7d3ebb834/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncMethodBuilderCore.cs#L21

[Lanayx]

I always use context insensitive builder in my apps and find it very convenient that I don't need to write ConfigureAwait(false) everywhere.

[blakeSaucier]

We use task builder with ASP.Net (Giraffe) and Azure Functions. We use context insensitive.

[davidglassborow]

F# has a few obscure open-able modules that very fe people end up using. Does anyone really do

open Checked

or

open NullableOperators

or

open NonStructuralComparison

I had a quick search on docs, found the info on nullable operators, but couldn't find anything about opening Checked ( arithmetic-operators mentions Microsoft.FSharp.Core.Operators.Checked, is that the same ?), nor any docs on a NonStructuralComparison module.

[dsyme]

is that the same

yes

nor any docs on a NonStructuralComparison module.

Some docs are here, but yes it should be in the language reference.

https://fsharp.github.io/fsharp-core-docs/reference/fsharp-core-operators-nonstructuralcomparison.html

[LiteracyFanatic]

Recently worked on a small GUI made with Avalonia.FuncUI which needed to make a bunch of calls to an external service using HttpClient. I was using Ply rather than the original TaskBuilder, but they're pretty similar. Not having to worry about the UI locking up because of a missing ConfigureAwait(false) was pretty convenient.