Repository navigation
Add reactor thread workers - #820
Open
andrewfader wants to merge 2 commits into
Open
andrewfader wants to merge 2 commits into
andrewfader wants to merge 2 commits into
Conversation
Thread workers run jobs without an Async reactor, so a client built on Async, like async-http, starts one per call and pays for a new connection and TLS handshake each time. Fiber workers keep a reactor, but run every job on one thread, where a job that blocks without yielding (a C extension decoding an image, CPU-heavy Ruby) stalls the rest. `reactor: true` on a thread worker keeps the thread pool and gives each thread a reactor that lives as long as the thread, running its jobs one at a time. Clients then reuse their connections across calls and jobs. Like the fiber pool, threads start lazily so the pool can be built before forking, and a cancelled reactor marks the pool as fatal. It requires the async gem but not fiber-scoped isolation, and database pool sizing is the same as for threads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
andrewfader
marked this pull request as ready for review
October 23, 2026 03:30
andrewfader
force-pushed
the
reactor-thread-workers
branch
from
October 24, 2026 19:26
3cdbf59 to
a549ba2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thread workers run jobs without an Async reactor, so clients built on Async, like
async-http, start one per call and pay for a new connection and TLS handshake every time. Fiber workers (#728) keep a reactor, but run every job on one thread, where a job that blocks without yielding (a C extension decoding an image, CPU-heavy Ruby) stalls the others.reactor: trueon a thread worker keeps the thread pool and gives each thread a reactor that lives as long as the thread, running its jobs one at a time:It's a new
ReactorThreadPoolalongsideThreadPoolandFiberPool. Threads start lazily so the pool can be built before forking, a cancelled reactor marks the pool as fatal, and shutdown drains queued executions. It needs theasyncgem but not fiber-scoped isolation, and database pool sizing is unchanged fromthreads.reactorwithfibersis rejected.Measured in an app making 10 sequential HTTPS calls per job, 12 jobs across 3 thread workers: per-call reactors opened 120 TLS sessions in 12.5–30.1s; reactor threads opened 3 in 7.9–8.9s.
Pool tests mirroring the fiber pool's, configuration validation, and a
reactor_threadentry in the worker execution-mode matrix.