Consider adding TaskCompletionSource.SetFromTask(Task)

[davidfowl]

EDITED by @stephentoub on 1/21/2023:

• I added Try methods.

namespace System.Collections.Threading.Tasks
{
    public class TaskCompletionSource
    {
+        public void SetFromTask(Task task);
+        public bool TrySetFromTask(Task task);
    }

    public class TaskCompletionSource<T>
    {
+        public void SetFromTask(Task<T> task);
+        public bool TrySetFromTask(Task<T> task);
    }
}

These methods require that the task argument has already completed and transfer the result/exception/cancellation state over to the TCS's Task.

Background and Motivation

A common operation when writing async code is to execute code that returns a task and complete. This usually involves creating a TaskCompletionSource to represent the operation, then executing the operation that returns a task at point in the future, then setting the result on completion to either failed, cancelled or success.

Proposed API

namespace System.Collections.Threading.Tasks
{
    public class TaskCompletionSource
    {
+       public void SetFromTask(Task task);
    }

    public class TaskCompletionSource<T>
    {
+       public void SetFromTask(Task<T> task);
    }
}

Usage Examples

public class Connection
{
    private TaskCompletionSource _tcs = new();
    private CancealltionTokenSource _cts = new();

    public Task Run()
    {
        ThreadPool.QueueUserWorkItem(_ => Start());
        return _tcs.Task;
    }
    
    public void Start()
    {
        tcs.SetFromTask(NetworkHelper.StartConnectionAsync(_cts));
    }
    // ...
}

This is a common pattern when you need to kick off an async operation and can't directly wait the operation inline.

Alternative Designs

Do this manually.

public static class TaskCompletionSourceExtensions
{
    public void SetFromTask(this TaskCompletionSource  task, Task task)
    {
        async Task Continue()
        {
            try
            {
                await task;
                tcs.TrySetResult();
            }
            catch (OperationCancelledException ex)
            {
               tcs.TrySetCancelled(ex.Cancelled);
            }
            catch (Exception ex)
            {
               tcs.TrySetException(ex);
            }
        }
        _ = Continue();
    }
}

Risks

None.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @tarekgh
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and Motivation

A common operation when writing async code is to execute code that returns a task and complete. This usually involves creating a TaskCompletionSource to represent the operation, then executing the operation that returns a task at point in the future, then setting the result on completion to either failed, cancelled or success.

Proposed API

namespace System.Collections.Threading.Tasks
{
    public class Task
    {
+       public void ContinueWith(TaskCompletionSource tcs);
    }

    public class Task<T>
    {
+       public void ContinueWith(TaskCompletionSource<T> tcs);
    }
}

Usage Examples

public class Connection
{
    private TaskCompletionSource _tcs = new();
    private CancealltionTokenSource _cts = new();

    public Task Run()
    {
        ThreadPool.QueueUserWorkItem(_ => Start());
        return _tcs.Task;
    }
    
    public void Start()
    {
        NetworkHelper.StartConnectionAsync(_cts).ContinueWith(tcs);
    }
    // ...
}

This is a common pattern when you need to kick off an async operation and can't directly wait the operation inline.

Alternative Designs

Do this manually.

public static class TaskExtensions
{
    public void ContinueWith(this Task task, TaskCompletionSource tcs)
    {
        async Task Continue()
        {
            try
            {
                await task;
                tcs.TrySetResult();
            }
            catch (OperationCancelledException ex)
            {
               tcs.TrySetCancelled(ex.Cancelled);
            }
            catch (Exception ex)
            {
               tcs.TrySetException(ex);
            }
        }
        _ = Continue();
    }
}

Risks

None.

Author:	davidfowl
Assignees:	-
Labels:	api-suggestion, area-System.Threading.Tasks, untriaged
Milestone:	-

[stephentoub]

We've considered such a thing in the past, e.g. tcs.SetFromTask(task). But we frequently found that there was a better way of writing it. For example, in your usage example:

public class Connection
{
    private TaskCompletionSource _tcs = new();
    private CancealltionTokenSource _cts = new();

    public Task Run()
    {
        ThreadPool.QueueUserWorkItem(_ => Start());
        return _tcs.Task;
    }
    
    public void Start()
    {
        NetworkHelper.StartConnectionAsync(_cts).ContinueWith(tcs);
    }
    // ...
}

passing the tcs into StartConnectionAsync and having it complete it.

public class Connection
{
    private TaskCompletionSource _tcs = new();
    private CancealltionTokenSource _cts = new();

    public Task Run()
    {
        ThreadPool.QueueUserWorkItem(_ => Start());
        return _tcs.Task;
    }
    
    public void Start()
    {
        NetworkHelper.StartConnectionAsync(_tcs, _cts);
    }
    // ...
}

or if StartConnectionAsync actually returned a Task (since I know how much you love async void methods), just using Task.Run:

public class Connection
{
    private CancealltionTokenSource _cts = new();

    public Task Run() => Task.Run(() => Start());
    
    public Task Start() => NetworkHelper.StartConnectionAsync(_cts);
    // ...
}

which does such transfer automatically.

[davidfowl]

• I have a delegate that I can't change the signature of, so I can't pass the all the way down.
• Task.Run doesn't work for me because I need to get rid of the ExecutionContext. I'm using my new favorite method UnsafeQueueUserWorkItem.
• I prefer the name SetFromTask on the TaskCompletionSource.

[stephentoub]

Task.Run doesn't work for me because I need to get rid of the ExecutionContext

You can of course use SuppressFlow. Yes, it's more code, but such a SetFromTask would need to be used enough to make it worthwhile.

Are you using UnsafeQueueUserWorkItem purely for the ExecutionContext behavior? Or do you actually need to queue the invocation of the async operation for some reason?

This still seems to me to be too niche to warrant exposing. The sole place we have such a SetFromTask method is in the implementation of Task.Run itself.

How many places would you actually use this?

[davidfowl]

Are you using UnsafeQueueUserWorkItem purely for the ExecutionContext behavior? Or do you actually need to queue the invocation of the async operation for some reason?

I need both behaviors.

This still seems to me to be too niche to warrant exposing. The sole place we have such a SetFromTask method is in the implementation of Task.Run itself.

Yea, it's not a big deal. I wrote a helper but I remembered that I also wrote a helper when we did the original SignalR (https://github.com/SignalR/SignalR/blob/75126981cd165fb57db4e38e9379e651fec1ecdf/src/Microsoft.AspNet.SignalR.Core/TaskAsyncHelper.cs#L315)

How many places would you actually use this?

I'll look around. I don't think it's critical at the moment, I filed this because it came up again in code I was writing and I didn't the first time

[theodorzoulias]

@davidfowl an existing alternative of the proposed API is to use a cold nested task and the Unwrap method. The Unwrap resembles the TaskCompletionSource.SetFromTask, in that it returns a proxy of the inner task. The completion status of the inner task is propagated through the proxy.

public class Connection
{
    private Task<Task> _taskTask;
    private CancellationTokenSource _cts = new();

    public Connection()
    {
        _taskTask = new Task<Task>(() => NetworkHelper.StartConnectionAsync(_cts));
    }

    public Task Run()
    {
        ThreadPool.QueueUserWorkItem(_ => _taskTask.RunSynchronously(TaskScheduler.Default));
        return _taskTask.Unwrap();
    }
    // ...
}

[davidfowl]

Man I forgot about Unwrap m. Async/await made me forget past trauma.

[davidfowl]

Do cold tasks capture the execution context?

[theodorzoulias]

Do cold tasks capture the execution context?

I wish I knew that!