Schedule synchronous function to separate thread - #312
Conversation
|
Ideally this is merged after: So I can solve the merge conflict and add necessary changes. |
|
About 561c22c, please see: QubesOS/qubes-core-admin-client#469 (comment) |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026072016-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests15 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 21 fixed
Unstable testsDetails
Performance TestsPerformance degradation:28 performance degradations
Remaining performance tests:83 tests
|
17ed68f to
7482948
Compare
|
I tests this PR with a qube that can shutdown normally and a freezed qube. Sometimes I set those qube to shutdown to have dependencies, so it fail with "in use" if not using force. Tested system:
Tested actions:
|
| _( | ||
| "The following error occurred while attempting to restart" | ||
| "qube {0}:\n{1}" | ||
| "The following error occurred while attempting to start" |
There was a problem hiding this comment.
I think that it is better to say which stage of "restart" failed, in this case, the "start" stage and not the "shutdown" stage.
There was a problem hiding this comment.
Still, I'd like it to still clarify it's during a restart, not during a pure start operation. "The following error occurred when restarting the qube during the start stage:" ?
| _( | ||
| "The following error occurred while attempting to shut" | ||
| "down qube {0}:\n{1}" | ||
| "The following error occurred while attempting to kill" |
There was a problem hiding this comment.
The line above has self.vm.kill, so I prefer to be explicit that the error happened on "kill", and not "shut down", as those are different things.
Waiting for the server to send the result of the API calls, allows dealing with failures/exceptions: - QubesVM.shutdown -> .shutdown(wait=True) - QubesVM.run_service -> .run_service_for_stdio It also does not block the widget from being opened again even if an action is still running. This allows, for example: - To create disposable qube and attach device to it (which takes 10s), but not block the widget from opening - To detach and shutdown disposable that is hanging, without hanging the widget For: QubesOS/qubes-issues#10648 For: QubesOS/qubes-issues#10651 For: QubesOS/qubes-issues#10835 Requires: QubesOS/qubes-core-admin#807 Requires: QubesOS/qubes-core-admin-client#469
Co-authored-by: Ben Grande <ben@invisiblethingslab.com> Fixes: QubesOS/qubes-issues#10651 Fixes: QubesOS/qubes-issues#10835
Allows the widget to be destroyed before the action completes.
ad0f5e3 to
26eaad9
Compare
|
The updater part got more comprehensive fix in #322 and this PR needs a rebase now. |
Waiting for the server to send the result of the API calls, allows dealing with failures/exceptions:
It also does not block the widget from being opened again even if an action is still running. This allows, for example:
For qui/tray/domains.py, the "widget.destroy()" is called earlier, cause it's not needed after the response is received. Else it hangs until the "react_to_question" finishes.
For: QubesOS/qubes-issues#10648
For: QubesOS/qubes-issues#10651
For: QubesOS/qubes-issues#10835
Requires: QubesOS/qubes-core-admin#807
Requires: QubesOS/qubes-core-admin-client#469