Doubts about Control.InvokeAsync implementation

[KalleOlaviNiemitalo]

The .NET 9 release notes for Windows Forms mentioned that Control.InvokeAsync #4631 is now available. Out of curiosity, I looked at how it was implemented, but I have some doubts about whether it’s correct.

1. If given a CancellationToken whose cancellation has already been requested, Control.InvokeAsync appears to return a Task that has already run to completion. I’d expect it to return a canceled task, instead.
2. There seems to be a race condition in cancellation: WrappedCallback might notice the cancellation request first and call completion.TrySetCanceled, and then completion.SetCanceled might also be called because of CancellationToken.Register; but the completion was already set so SetCanceled would throw in this case. Perhaps this could be demonstrated by first registering another cancellation callback that sleeps a bit to give WrappedCallback some time to act before SetCanceled is called.
3. If InvokeAsync calls BeginInvoke, but the thread that owns the target Control then terminates before the window message is handled, I think the Task returned by InvokeAsync will hang and never complete (unless canceled via CancellationToken). I’d expect the Task to fail with InvalidAsynchronousStateException. This looks unfixable as long as InvokeAsync uses BeginInvoke, but could perhaps be fixed by saving the TaskCompletionSource into the ThreadMethodEntry and faulting it if the queue is cleared without callbacks being executed.

[elachlan]

@KlausLoeffelmann will be interested in the feedback on InvokeAsync