Skip to content

Implement thread pool with work-stealing scheduler#285

Open
nbeerbower wants to merge 2 commits into
mainfrom
claude/thread-pool-work-stealing-cJr03
Open

Implement thread pool with work-stealing scheduler#285
nbeerbower wants to merge 2 commits into
mainfrom
claude/thread-pool-work-stealing-cJr03

Conversation

@nbeerbower

Copy link
Copy Markdown
Collaborator

This replaces the previous approach of creating a new pthread for every
spawn() call with a fixed-size thread pool that reuses worker threads.
Workers can steal tasks from each other to balance load automatically.

Key changes:

  • Add work-stealing thread pool with Chase-Lev deques
  • Workers default to CPU count threads (configurable)
  • Per-worker local deques with lock-free push/pop
  • Random work stealing when local deque is empty
  • Global submission queue for external spawn() calls
  • Shutdown drains all pending work gracefully

Both interpreter and compiler runtime use the same design, maintaining
parity between the two backends.

This prevents runaway thread creation when spawning many async tasks
while still maintaining good parallelism through work stealing.

claude added 2 commits January 3, 2026 21:42
This replaces the previous approach of creating a new pthread for every
spawn() call with a fixed-size thread pool that reuses worker threads.
Workers can steal tasks from each other to balance load automatically.

Key changes:
- Add work-stealing thread pool with Chase-Lev deques
- Workers default to CPU count threads (configurable)
- Per-worker local deques with lock-free push/pop
- Random work stealing when local deque is empty
- Global submission queue for external spawn() calls
- Shutdown drains all pending work gracefully

Both interpreter and compiler runtime use the same design, maintaining
parity between the two backends.

This prevents runaway thread creation when spawning many async tasks
while still maintaining good parallelism through work stealing.
When tasks block on channels or I/O, having only CPU count workers
can cause deadlock-like situations where all workers are waiting.
Using 2x CPU count provides headroom for blocking tasks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants