letztes Jahr haben wir vier verschiedene Varianten gezeigt, die jeweils unterschiedliche Lib-Dependencies hatten. Deshalb war es ein Multimodule-Projekt. Das kann ich diesmal vereinfachen in ein einziges Projekt
- - +die Zuhörer sind keine Systemprogrammierer
- - +allerdings: der Worker wäre damit ein Proactor
- - +....es wäre nämlich tatsächlich dann ganz ideomatisch (so hab ich die Doku verstanden, und Claude sagt das von sich aus auch). @@ -1002,8 +991,7 @@ Zwar hatte ich die Idee, im Talk schon grundsätzlich etwas zu machen, was funktioniert wie in Lumiera geplant. Aber wenn ich mir das wirklich vom didaktischen Gesichtspunkt her nochmal überlege, ist es nicht so geschickt.
- - +...es würde zur "toolkit, nicht framework"-Policy passen, und zudem wäre das Signal explizit von jedem Thread aus triggerbar
- - ++ // --- GUI thread, once at setup --- +
++ Glib::Dispatcher frameReady; +
++ frameReady.connect([this]{ displayFrame(*processor_); }); // upload + draw + eglSwapBuffers() +
++ +
++ // --- worker thread, once a frame is ready --- +
++ frameReady.emit(); // thread-safe; wakes the GUI thread's main loop +
+ + +Ich verwende das aktuelle "Sonnet" auf Stufe Medium. Das braucht erhebliche Rechenzeit für jede Antwort auf diesem Diskussionslevel (und zeigt auch jeweils expandierende, schlußfolgernde und kondensierende Phasen an)
- - +Proactor, confirmed. io_uring is the textbook proactor: you submit a description of the completed operation you want, the kernel does the work, and your thread's job is purely to consume results and act on them — as opposed to a reactor (epoll-style), where you're told "this fd is ready," and you still perform the (potentially blocking, now guaranteed-non-blocking) I/O yourself. Good instinct to name this explicitly in the talk; it's the single sentence that makes the rest of the design legible. @@ -1147,27 +1153,21 @@ Given that framing: you're right that a flag-per-buffer is not a lesser or simplified version of "the real solution" — it's the same solution as coroutines, just written manually because your problem is small and linear enough that the compiler-generated version would be pure overhead (both in runtime terms and, more importantly here, in audience cognitive load — introducing C++20 coroutine machinery to explain a 3-state pipeline would be a bad trade for this talk).
- - +std::atomic<SlotState>
- - +std::atomic<SlotState> with release-on-write / acquire-on-read is enough — no mutex needed. That pairing is worth a beat in the talk on its own: the atomic isn't there to prevent concurrent writes (there aren't any), it's there to guarantee the GUI thread sees the buffer contents the worker wrote, not just the state flag — a clean, concrete illustration of why acquire/release exists, tied directly to something the audience just watched you build.
-
-
+
...obschon man sie auf dem gleichen lokalen State aufbaut. Das Beispiel, das Claude nennt: man könnte das Quellfile loopen
- - +struct io_uring ring; @@ -1316,14 +1310,11 @@ io_uring_submit(&ring); // one syscall flushes everything prepped above
- - +for (;;) { @@ -1362,31 +1353,24 @@ }
- - +
The reason top-up belongs in onTick rather than in onReadComplete:
a slot only becomes reusable once the GUI thread has finished drawing it and flips it back to Empty — and the worker, sitting blocked in io_uring_wait_cqe, has no way to know that happened except by waking up for something. The tick is that guaranteed periodic wake-up, so it doubles as "check if there's new capacity to fill," with a worst-case latency of one tick period (~40ms) before a freed slot gets reused — fine at this cadence, and a nice illustration that the timer isn't just pacing display, it's also the thing that keeps the whole state machine alive even when nothing else is happening.
bestätigt meine Analyse, ohne Diskrepanz
- - +
Ja, weiß ich. Deshalb hab ich's so programmiert. Freut mich daß Claude da unabhängig zum gleichen Schluß kommt (denn ich hab mich oft gefragt, ob ich mich da in Spitzfindigkeiten verrenne).
Also nochmal explizit: memory_order_relaxed reicht hier nicht
Einmal geht es um shared-data zwischen Kernel und Userspace. Wohingegen das Grooming-Token die Sichtbarkeit über die Worker hinweg steuert. @@ -1542,8 +1515,7 @@ Diese Unterscheidung ist konzeptionell (sehe ich so, Claude deutet es auch so). Beide Ansätze stören sich nicht, man sollte sie aber auseinanderhalten. Ich denke, das ist ein generischer guter Rat beim Design solcher Systeme, man sollte nicht danach streben, solche verschiedenen Belange zusammenzufassen, selbst wenn es im konkreten Fall möglich wäre (wie hier der Fall, aber nur weil keine data-dependenciy im memory-ordering includiert ist)
- - +Current 2 — thread-per-core, shared-nothing, and it's picking up real steam. This is the more consequential trend to be aware of, because it's a genuinely different answer to the same problem you're solving, and it's currently the fashionable one in high-performance I/O-heavy systems: pin one thread per core, partition data and work by that core (typically via hashing), eliminate cross-thread shared state entirely, and communicate exclusively via message passing rather than shared queues or locks. This is the architecture behind ScyllaDB and Redpanda via the Seastar framework, and it's spreading into the Rust ecosystem too (Glommio, compio, and others). A recent writeup from the Apache Iggy project frames the shift precisely as moving from work stealing to "work steering" — i.e., instead of idle workers reaching into a shared structure (what you have), work is routed to the specific core that already owns the relevant data, and nobody has to contend for anything. Interestingly, the standard advice against a single shared io_uring instance per application is exactly the contention concern we discussed for your ring — each thread in Glommio gets its own private set of rings instead, which is the thread-per-core answer to the same "who owns the ring" question you and I just spent a while on. Apache + 2
- - +aber man sollte konzeptionell zwischen der visibility mit dem Kernel und der Visibility zwischen den Workern unterscheiden; für ersteres gibt es die Barrieren in Liburing
- - +der Umstand daß neue IO-Aktivitäten gescheduled werden und Completions entnommen werden müssen, garantiert nur eine passive Backpressure (nicht entnommene Completions gehen nicht verloren, und der Platz in den URings ist begrenzt). Sehr wahrscheinlich ist mehr notwendig, damit die Engine rund läuft.
- - +Es ist eine etablierte und bewährte Methode, und wird nicht weggehen. Was wir geschaffen haben konvergiert gut mit den allgemeinen Einsichten im Feld
- - +das ist ein Gegentrend, der aber auf einer anderen Größenordnung arbeitet (im Nanosekunden-Bereich)
- - ++ Hier möchte ich sowohl den GTK-Code selber verbergen, alsauch dem Umstand daß die Start-Lokik in der Applikation nicht ganz trivial ist, und mit dem Start des Players verwoben. Lesbarkeit ist eine weitere Motivation: man kann dadurch Dinge benennen +
+ + ++ dazu gehört auch, keine »Tricks« anzuwenden und keine schlechten Praktiken vorzuführen. Der Zustands-Träge sollte unique sein, ohne Wenn und Aber. +
+ + +...anders als bei dem Video-Output-Thema, bei dem wir uns die zentralen Element überhaupt erst aufschließen mußten, und dies nur mithilfe bestehender GPL-Codebasen geschafft haben. Diesmal ist die Situation ganz anders, das Thema ist ziemlich gut in Tutorials und Blogs aufbereitet. Viele haben zwar kein brauchbares Lizenz-Statement, aber andererseits ist die Aufgabe so einfach, daß ich nirgends Code abschreiben muß, den ich nicht auch genauso selber schreiben könnte.
- - +