fix(perf): run network git ops off the main thread#6
Merged
Conversation
push/push_force/pull/fetch were bare #[tauri::command], so their blocking remote IO ran on the main/IPC thread and froze the webview for seconds - visible as a UI stutter when picking a pull/fetch action. Mark them (async) like the other heavy commands so they run on a worker thread. That removes the implicit backend serialization those blocking commands had, so add a synchronous re-entrancy guard in RepoView.run() (busyRef, not the render-lagged busy state) so a rapid double-trigger - e.g. the pull/push keyboard shortcut hit twice - can't launch two concurrent git ops racing on the same .git lock files. The now-redundant busy->busyRef mirror effect is dropped; run() owns busyRef directly.
|
🎉 This PR is included in version 0.28.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Selecting a pull/fetch action (or pushing) froze the UI for a few seconds before the action completed - a visible stutter, not smooth.
Cause
push,push_force,pull,fetchwere bare#[tauri::command], so Tauri ran their bodies on the main/IPC thread. Their blocking remote IO (git subprocess over the network) blocked the webview for the whole operation. Every other heavy command already uses#[tauri::command(async)](worker thread) - the network ops were missed.Fix
(async)so they run off the main thread. The synchronous bodies each own their ownRepositoryand never await, so the spawned future isSend(same invariant the existing async commands rely on).(async)removes that, so a rapid double-trigger (e.g. the pull/push keyboard shortcut hit twice) could now launch two concurrent git ops racing on the same.gitlock files. Add a synchronous re-entrancy guard inRepoView.run()usingbusyRef(not the render-laggedbusystate) so only one op runs at a time, regardless of trigger (button or keyboard).busy->busyRefmirror effect;run()ownsbusyRefdirectly.Verification
cargo checkcleantsc --noEmitclean