You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simplify IOController pool identity and address PR review feedback.
Move pool constexprs onto IOController, raise poll to NORMAL priority, colocate inline bump reactions with their handlers, inline the poll loop, and bring Windows onto the same scheduler-driven model.
Co-authored-by: Cursor <cursoragent@cursor.com>
Some extensions use a single-consumer pool with a blocking wait in the worker thread (for example, IOController on POSIX blocks in `::poll()`). Priority does not preempt inside the blocking call; instead, cross-thread control work is enqueued at HIGH priority on the same pool, a notify pipe wakes the poll thread, the LOW poll task finishes its iteration and resubmits, and the worker dequeues the already-queued HIGH task before the resubmitted poll. Control handlers that mutate poll state from another thread pair with separate default-pool bump reactions registered after the HIGH handlers so the bump runs from a thread that is not blocked in `::poll()`.
280
+
Some extensions use a single-consumer pool with a blocking wait in the worker thread.
281
+
For example, IOController blocks in `::poll()` or `WSAWaitForMultipleEvents()`.
282
+
283
+
Priority does not preempt inside the blocking call.
284
+
Instead, cross-thread control work is enqueued at HIGH priority on the same pool.
285
+
An inline bump reaction writes the notify pipe or event from the emitting thread.
286
+
The poll task finishes its iteration and resubmits at NORMAL priority.
287
+
The worker then dequeues the already-queued HIGH task before the resubmitted poll.
Copy file name to clipboardExpand all lines: docs/reference/extensions/built-in-extensions.md
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,12 +95,13 @@ Monitors file descriptors for IO readiness events and triggers corresponding rea
95
95
96
96
**Implementation:**
97
97
98
-
**Implementation:**
99
-
100
-
Uses platform-native polling mechanisms:
98
+
Uses platform-native polling mechanisms on a dedicated `IOController` pool (`concurrency = 1`, MPSC):
101
99
102
-
-**POSIX (Linux/macOS):**`poll()` with `pollfd` arrays, driven by a dedicated `IOController` pool (`concurrency = 1`, MPSC). A LOW-priority poll task blocks in `::poll()` and resubmits itself after each iteration. Control handlers (`IOConfiguration`, `IOFinished`, `Unbind`, `Shutdown`) run at HIGH priority on the same pool; separate default-pool bump reactions wake the poll thread via a notify pipe once the HIGH task is queued.
103
-
-**Windows:**`WSAWaitForMultipleEvents` with `WSAEVENT` handles, still using `on<Always>` (scheduler-driven parity deferred).
100
+
-**POSIX (Linux/macOS):**`poll()` with `pollfd` arrays.
101
+
A NORMAL-priority poll task blocks in `::poll()` and resubmits itself after each iteration.
102
+
Control handlers (`IOConfiguration`, `IOFinished`, `Unbind`, `Shutdown`) run at HIGH priority on the same pool.
103
+
Each control handler is followed by an `Inline::ALWAYS` bump reaction that writes the notify pipe from the emitting thread.
104
+
-**Windows:**`WSAWaitForMultipleEvents` with `WSAEVENT` handles, using the same scheduler-driven pool and priority model.
104
105
105
106
When events are detected on registered file descriptors, the controller creates tasks for the corresponding reactions, passing the event flags through `ThreadStore` so the `get` method can report which specific events occurred.
0 commit comments