Equivalent of BeginInvoke for delaying work

[jaredpar]

A pattern that comes up in my VS extensions is to use Dispatcher.BeginInvoke to delay work to a later time. Essentially:

_ = Dispatcher.CurrentDispatcher.BeginInvoke(
  () => { 
    // Work to be done later 
   }, null);

The code is already known to be on the UI thread. It just uses BeginInvoke as a mechanism to let other work run now and run my follow up work on idle later on.

Attempting to move my code to use JoinableTaskFactory and struggling to find the correct pattern to replace this with. I can't decide which of the following is the most semantically equivalent to the above:

// Option 1
_ = JoinableTaskFactory.RunAsync( 
  async () => {
    await JoinableTaskFactory.SwitchToMainThreadAsync(); 
    // work to be done later 
  });

// Option 2
_ = JoinableTaskFactory.RunAsync( 
  async () => {
    await JoinableTaskFactory.SwitchToMainThreadAsync(); 
    await Task.Delay();
    // work to be done later 
  });

The case I worry about with Option 1 is whether everything could execute synchronously. Essentially if JoinableTaskFactory knows it's already on the UI thread can the entire operation complete synchornously? If so then the extra Task.Delay would be necessary to cause some delay in the work executing.

[Therzok]

There is an alwaysYield parameter you can pass to ensure the callback starts executing on the next UI loop iteration.

[sharwell]

Ah, right, which would look like this (I believe):

_ = JoinableTaskFactory.RunAsync( 
  async () => {
    await JoinableTaskFactory.WithPriority(DispatcherPriority.Background).SwitchToMainThreadAsync(alwaysYield: true); 
    // work to be done later 
  });

📝 If the JoinableTaskFactory instance comes from the AsyncPackage of the extension, it should already have DispatcherPriority.Background applied to it.

[jaredpar]

The alwaysYield parameter doesn't fully work for me because my extension still supports VS 2017 and that version of VS threading doesn't have it. That honestly just may be more reason to drop support for 2017 though. Thanks for the suggestion here!

[AArnott]

This is the closest equivalent:

_ = JoinableTaskFactory.RunAsync( 
  async () => {
    await Task.Yield();
    // work to be done later 
  });

This requires the condition you met that you know you're already on the UI thread. It will use the default priority for that JTF instance to get back to the UI thread once you get off of it.
If you didn't know you were on the main thread already, using SwitchToMainThreadAsync(alwaysYield: true) as @Therzok said is the best way to go since you want the delegate to run on the main thread.
WithPriority allocates a new object, so if you were to use that in high traffic code, you might want to use it once and store the result in a field for reuse.

If the callstack already has a JTF.Run on it, then the 'do later' work could get back on the UI thread because it will be seen as relevant to the overall JTF.Run delegate. If you don't want that, you'd have to mix SuppressRelevance into the mix.

If you're in code that can reference VS SDK assemblies, you can use StartOnIdle to easily ensure that the delegate will not execute till the main thread is back on the main message pump, and ready to process the priority you specify.

[jaredpar]

This requires the condition you met that you know you're already on the UI thread. It will use the default priority for that JTF instance to get back to the UI thread once you get off of it.

In all these cases I know I'm on the UI thread (handing ITextView events).

In the case I wanted to use a different priority other than the default, is @sharwell suggestion above the "best" approach?

[AArnott]

No. The recommended pattern is not to set priority when you're switching to the UI thread. That's conflating concerns. The priority should be set in the high-level task. So it would be better written like this:

_ = JoinableTaskFactory.WithPriority(DispatcherPriority.Background).RunAsync( 
  async () => {
    await Task.Yield();
    // work to be done later 
  });

Notice now that the priority will apply to all code within and derived from the delegate, instead of just one particular yielding await.

[jaredpar]

Thanks. Think I have enough to go on now!