diff --git a/src/vault/gear/scheduler.hpp b/src/vault/gear/scheduler.hpp
index 4d635d9f5..ebd80adf0 100644
--- a/src/vault/gear/scheduler.hpp
+++ b/src/vault/gear/scheduler.hpp
@@ -63,9 +63,17 @@ namespace gear {
// using util::isnil;
// using std::string;
+ namespace { // Scheduler default config
+
+ const auto IDLE_WAIT = 20ms;
+ const size_t DISMISS_CYCLES = 100;
+ }
- /**
- * Schedule and coordinate render activities.
+
+
+
+ /******************************************************//**
+ * »Scheduler-Service« : coordinate render activities.
* @todo WIP-WIP 6/2023
* @see BlockFlow
* @see SchedulerUsage_test
@@ -73,23 +81,30 @@ namespace gear {
class Scheduler
: util::NonCopyable
{
- using Setup = work::Config; ////////////////////////////////////////////////////OOO actually need subclass to attach the work-function
+ /** Binding of worker callbacks to the scheduler implementation */
+ struct Setup : work::Config
+ {
+ Scheduler& scheduler;
+ activity::Proc doWork() { return scheduler.getWork(); }
+ void finalHook (bool _) { scheduler.handleWorkerTermination(_);}
+ };
+
SchedulerInvocation layer1_;
SchedulerCommutator layer2_;
-// WorkForce
+ Schwere Geburt...
+
+ Irgendwie hatte sich bei mir die Idee mit den Lambdas so festgefressen — obwohl ich doch schon eingesehen hatte, daß C++ in der Hinsicht (aus gutem Grund) sehr konsequent ist, und keine Hintertür bietet, um Laufzeit-Bindigns in die statische Ebene „zu schmuggeln“. Was mich dann aber auch extrem gestört hat, waren die std::function-Felder, in die man die Lambdas speichern müßte. Es wäre nämlich eine andere Lösung denkbar, bei der diese Function-Objekte schon in der Basis-Config für die WorkForce enthalten sind; damit wäre das Design auch komplett festgelgt (und der Test würde sogar einfacher). Trotzdem habe ich eine Abneigung gegen diese Function-Objekte, weil sie eben komplett unnötig sind, da es sich effektiv um ein statisches Binding handeln sollte. Und das war dann das rettende Stichwort: dann definiert man eben diese Binding-Forwarder als statische Funktionen in einer nested Class, und macht die Rückreferenz auf den Scheduler explizit. Und mit Aggregat-Initialisierung kann man dann sogar noch die Definition des Konstruktors auslassen
+
+ Denn jeder Aufruf des Fork-Funktors wird unterschiedlich lang dauern. Und selbst wenn alle Worker idle sind: dann gibt es bei der ersten Runde die Mega-Contention, und danach liegen die Wartezyklen aller Worker leicht gestaffelt. Contention wäre nur dann ein Problem, wenn jemand, der arbeiten könnte, vom Arbeiten abgehalten wird.
+
+ ...wie so oft, vor allem getrieben durch die Tests: die Layer wurden zu einer Sammlung von Implementierungs-Bausteienen, welche auch aufeinander aufbauen. Aber die große Verdrahtung habe ich noch vor mir hergeschoben — sogar so weit, daß Layer-2 selbst keine Referenz auf Layer-1 besitzt (sondern diese für jede Funktion hereingereicht bekommt). Damit wird die Verdrahtung nun sternförmig, und der Binde-Code ist das, was den »Scheduler-Service« ausmacht +
+ + +- C++ zwingt uns dazu, explizit das zu tun was ohnehin getan werden muß; da jedoch der Typ der Config per Template-Parameter gewählt wird, ist komplettes Inlining möglich; letztlich wird daher nur ein Pointer auf das Scheduler-Objekt in alle Threads kopiert — exakt das was wir brauchen + C++ zwingt uns dazu, explizit das zu tun was ohnehin getan werden muß; da jedoch der Typ der Config per Template-Parameter gewählt wird, ist komplettes Inlining möglich; letztlich wird daher nur ein Pointer auf das Scheduler-Objekt in alle Threads kopiert — exakt das was wir brauchen
+