JoinableTask can be leaked easily through ExecutionContext, and causes task results to be leaked

[lifengl]

ExecutionContext is copied very often in any place to create a task continuation, or spin off an execution. The context will capture the current ambient task, and hold it even the task has been completed for a long time. This can easily leak the task result, which can be very big.

[AArnott]

@lifengl adds:

It is only when JTF.RunAsync/JTF.Run is used. When T is a simple value, it is generally not a problem. But when T is a complex value, it can be a problem.

For example

JTF.RunAsync<T> (async () =>
// …
someBackGroupThread.Start();
// …
});

If the background thread is long running thread, the returning value of the JTF task will be leaked. Of course, generally, we don’t start a such task inside a JTF task. Often, it happens when we initialize some other components. For example, a build manager may spin off a background task, so when we accidently initialize it within a JTF, it can cause the leak.

Another common place is to chain a dataflow link. When we ask it to PropagateCompletion, it will chain a task continuation, which captures whatever the current JTF task.

Of course, in many places, we can if it with JTFContext.SuppressRelevance(). But in the reality, it can happen in many places, which make it hard to apply.

[lifengl]

It is more than spinning off a task. More often, it is the lazy initialization code to chain up data source completion, or long term cancellation token registration (like project unloading cancellation token). All those will capture the current ExecutionContext, and apply them much later (often at the end of the session). That leads it to capture whatever the current JTF task, which happens to trigger the lazy calculation, and its result.

[AArnott]

I wonder if we can fix this by using a AsyncLocal<WeakReference<JoinableTask>>, thereby ensuring we never keep them around longer than is needful. One problem I see with this is we'd allocate another object, but maybe on the scale of allocations JoinableTask already make, that's not a big deal. Also, each JoinableTask can maintain its own weak reference in a field so we can reuse it rather than create a new one each time we assign to the AsyncLocal.