@KlausLoeffelmann will be interested in the feedback on InvokeAsync

Hi!

I recently started using Control.InvokeAsync() in one of my apps, and also stumbled upon point 1, that when passing an already canceled CancellationToken (or one that is canceled soon after calling the method), the returned Task would complete with a null/default value instead of being set to the canceled state, so I agree that this should be fixed to return a canceled task instead (maybe by calling CancellationToken.ThrowIfCancellationRequested()?).

Regarding point 2: Note that the race condition is not only due to TrySetCanceled() call in WrappedCallback, but also due to the TrySetResult() call that happens after the callback was executed: If the token is canceled between the TrySetResult() call (after the callback execution is complete) and the point where the CancellationTokenRegistration is disposed, the SetResult call from the CancellationTokenRegistration will throw an InvalidOperationException, which can result in an AggregateException being thrown by CancellationTokenSource.Cancel().
(This can be reproduced by inserting a Thread.Sleep() call between awaiting the completion.Task and disposing the CancellationTokenRegistration.)

I think one possibility to fix the race condition is by using TrySetCanceled instead of SetCanceled in the CancellationTokenRegistration callback, so that if either TrySetCanceled or TrySetResult already happened in the WrappedCallback, this won't throw an InvalidOperationException.

Thanks!