Modernize async processing

[NathanBaulch]

This project is full of Task.Run (157 calls) and Dispatcher.UIThread.Invoke (125 calls) to keep the UI responsive during I/O-bound operations (primarily waiting for git shell commands). As far as I can tell there's nothing CPU-bound in this app.

Rather than delegating I/O work to the thread pool and manually dispatching back to the UI thread, it's much better to take advantage of async/await for better responsiveness, lower overheads and more readable/linear code. More info here.

I've started working on this but it's quite a significant refactor and wanted to check that this is something of interest before putting too much time into it. Is now a good time to adopt modern async patterns?

[love-linger]

I will try to modify a version first and test its efficiency compared with the current one. Before that, please do not submit the relevant PR.

[NathanBaulch]

Sure. It's not just about efficiency though, it's also about code readability (unless you're also referring to development efficiency).

Two random examples:

// BEFORE
private void Gen()
{
    Text = string.Empty;
    IsGenerating = true;
    _cancel = new CancellationTokenSource();
    Task.Run(() =>
    {
        new Commands.GenerateCommitMessage(_service, _repo.FullPath, _changes, _cancel.Token, message =>
        {
            Dispatcher.UIThread.Invoke(() => Text = message);
        }).Exec();
        Dispatcher.UIThread.Invoke(() => IsGenerating = false);
    }, _cancel.Token);
}
// AFTER - able to use try-finally
private async Task GenAsync()
{
    Text = string.Empty;
    IsGenerating = true;
    try
    {
        _cancel = new CancellationTokenSource();
        await new Commands.GenerateCommitMessage(_service, _repo.FullPath, _changes, _cancel.Token, 
            message => Text = message).ExecAsync();
    }
    finally
    {
        IsGenerating = false;
    }
}

// BEFORE
public override Task<bool> Sure()
{
    _repo.SetWatcherEnabled(false);
    ProgressDescription = "Archiving ...";
    var log = _repo.CreateLog("Archive");
    Use(log);
    return Task.Run(() =>
    {
        var succ = new Commands.Archive(_repo.FullPath, _revision, _saveFile).Use(log).Exec();
        log.Complete();
        CallUIThread(() =>
        {
            _repo.SetWatcherEnabled(true);
            if (succ)
                App.SendNotification(_repo.FullPath, $"Save archive to : {_saveFile}");
        });
        return succ;
    });
}
// AFTER - uses a helper func DisableWatcher that re-enables watcher on dispose
public override async Task<bool> Sure()
{
    using (_repo.DisableWatcher())
    {
        ProgressDescription = "Archiving ...";
        var log = _repo.CreateLog("Archive");
        Use(log);
        var succ = await new Commands.Archive(_repo.FullPath, _revision, _saveFile).Use(log).ExecAsync();
        log.Complete();
        if (succ)
            App.SendNotification(_repo.FullPath, $"Save archive to : {_saveFile}");
        return succ;
    }
}

Another nice side-effect is better separation of concerns since the SourceGit.Command namespace would no longer need to reference Avalonia.Threading.

[love-linger]

Points that need attention are as follows:

1. The place where an event is called at the very beginning may not be the UI thread, such as FileSystemWatcher, Timer, etc.
2. Sometimes we execute some operations in parallel, for example, when pressing F5 to refresh the repository operation, or updating the CommitDetail panel.
3. Some code may not only be IO-bound, such as parsing a large number of commits.

[NathanBaulch]

Agreed, in those scenarios Task.Run (or Task.When*) and/or UIThread.Invoke would still be used. In some cases there might be better approaches, eg Avalonia.Threading.DispatcherTimer.

[love-linger]

You can also create PR directly. I will push a feature/async branch later. Please set the target to it.