diff --git a/src/vault/gear/scheduler-commutator.hpp b/src/vault/gear/scheduler-commutator.hpp
index a882fc12d..7a64f0460 100644
--- a/src/vault/gear/scheduler-commutator.hpp
+++ b/src/vault/gear/scheduler-commutator.hpp
@@ -315,7 +315,8 @@ namespace gear {
~ScopedGroomingGuard()
{
- if (handledActively_)
+ if (handledActively_ and
+ commutator_.holdsGroomingToken(thisThread()))
commutator_.dropGroomingToken();
}
};
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 3d32455d6..48b3d78fa 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -105226,8 +105226,7 @@ Date: Thu Apr 20 18:53:17 2023 +0200
dieses Prinzip könnte man aufweichen — ich halte das aber für eine schlechte Idee, denn der Scheduler ist auch so schon schwer genug zu verstehen, auch die Activity-Language beginnt schon zu »bröseln« ... gefährliche Tendenz. Meine Einschätzung ist, wir planen ehr so 10 Jobs pro Metajob-Lauf, d.h. das wären dann Größenordnung 500-1000µs Zeit, in der jedwede andere Management-Tätigkeit geblockt ist (renderjobs laufen trotzdem weiter). Sofern diese Annahme nicht zutrifft, möchte ich dafür konkrete Beweise sehen