fix: ensure loading_screen! generated thread joins before exiting patch-hub#122
Closed
lorenzoberts wants to merge 1 commit intokworkflow:unstablefrom
Closed
fix: ensure loading_screen! generated thread joins before exiting patch-hub#122lorenzoberts wants to merge 1 commit intokworkflow:unstablefrom
lorenzoberts wants to merge 1 commit intokworkflow:unstablefrom
Conversation
…ch-hub This commit fixes the cursor becoming invisible when crash occur during loading. The problem was caused by not joining the thread generated by loading_screen! before handling the error (e.g exiting patch-hub). The solution was achieved by the following changed: 1. Made the closure that's passed to the loading_screen! macro return a Result instead of (), enabling proper handling of the result after joining the loading thread. 2. Changed the closures to avoid propagating errors using the ? operator, as in Rust, "?" and "return" are applied to the outer function instead of the closure itself. Closes: kworkflow#74 Signed-off-by: Lorenzo Bertin Salvador <lorenzobs@usp.br>
lorenzoberts
force-pushed
the
lorenzo/solve-cursor-missing
branch
from
e73747a to
c196644
Compare
Collaborator
|
Hi @lorenzoberts. First of all, I am sorry about the delay 😓 I hate giving excuses, but things have been hectic in the last months... Anyway, thank you so much for this awesome fix! I must confess that I had not many hopes on solving this bug, as I couldn't elaborate the cause of it, but your PR not only fixed it gracefully, but also made sense of it to me 😺 Thank you so much, great PR, and change merged into the unstable branch 👍 |
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
2 participants
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.
This PR fixes #74.
Besides what I've described in the commit message, I would like to point out that this issue is a great example why we should always avoid unwraps and gracefully handle errors. Even though the problem was not caused by any unwraps, the problematic behavior will continue to happen if the code panics before joining the loading screen thread.
I chose to focus on resolving the bug itself, which is why I didn’t remove any unwrapping from the related logic. Additionally, as I mentioned in the commit message, it’s important for us to pay attention to how Rust handles closures. I’m not sure if what we were doing was intentional, but at least for me, it’s counterintuitive that the
?andreturninside a closure don’t apply to the closure itself. @davidbtadokoro , if you can remember any other places where we might have handled this incorrectly, let me know, and I can fix it.