[education/rkward] rkward/rbackend: Fix detection of interrupted commands on Windows
Thomas Friedrichsmeier
null at kde.org
Fri Jun 17 14:34:30 BST 2022
Git commit 4edde95af8411abaa41ccbe93fcc049b563dbdc2 by Thomas Friedrichsmeier.
Committed on 17/06/2022 at 13:34.
Pushed by tfry into branch 'master'.
Fix detection of interrupted commands on Windows
M +4 -0 rkward/rbackend/rkrbackend.cpp
https://invent.kde.org/education/rkward/commit/4edde95af8411abaa41ccbe93fcc049b563dbdc2
diff --git a/rkward/rbackend/rkrbackend.cpp b/rkward/rbackend/rkrbackend.cpp
index b9faa368..fae358c6 100644
--- a/rkward/rbackend/rkrbackend.cpp
+++ b/rkward/rbackend/rkrbackend.cpp
@@ -902,7 +902,11 @@ void doError (const QString &callstring) {
if (RKRBackend::repl_status.interrupted) {
// it is unlikely, but possible, that an interrupt signal was received, but the current command failed for some other reason, before processing was actually interrupted. In this case, R_interrupts_pending if not yet cleared.
// NOTE: if R_interrupts_pending stops being exported one day, we might be able to use R_CheckUserInterrupt() inside an R_ToplevelExec() to find out, whether an interrupt was still pending.
+#ifdef Q_OS_WIN
+ if (!UserBreak) {
+#else
if (!R_interrupts_pending) {
+#endif
RKRBackend::repl_status.interrupted = false;
if (RKRBackend::repl_status.user_command_status != RKRBackend::RKReplStatus::ReplIterationKilled) { // was interrupted only to step out of the repl iteration
QMutexLocker lock (&(RKRBackend::this_pointer->all_current_commands_mutex));
More information about the rkward-tracker
mailing list