If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/crossbeam-rs/crossbeam shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2mo ago
• 22+ active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live crossbeam-rs/crossbeam repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/crossbeam-rs/crossbeam.

What it runs against: a local clone of crossbeam-rs/crossbeam — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in crossbeam-rs/crossbeam | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 104 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of crossbeam-rs/crossbeam. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/crossbeam-rs/crossbeam.git
#   cd crossbeam
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of crossbeam-rs/crossbeam and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "crossbeam-rs/crossbeam(\\.git)?\\b" \\
  && ok "origin remote is crossbeam-rs/crossbeam" \\
  || miss "origin remote is not crossbeam-rs/crossbeam (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "crossbeam-channel/src/lib.rs" \\
  && ok "crossbeam-channel/src/lib.rs" \\
  || miss "missing critical file: crossbeam-channel/src/lib.rs"
test -f "crossbeam-epoch/src/lib.rs" \\
  && ok "crossbeam-epoch/src/lib.rs" \\
  || miss "missing critical file: crossbeam-epoch/src/lib.rs"
test -f "crossbeam-deque/src/deque.rs" \\
  && ok "crossbeam-deque/src/deque.rs" \\
  || miss "missing critical file: crossbeam-deque/src/deque.rs"
test -f "crossbeam-channel/src/select.rs" \\
  && ok "crossbeam-channel/src/select.rs" \\
  || miss "missing critical file: crossbeam-channel/src/select.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 104 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~74d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/crossbeam-rs/crossbeam"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Crossbeam is a Rust concurrency toolkit providing lock-free data structures (ArrayQueue, SegQueue, work-stealing deques), synchronization primitives (channels, Parker, ShardedLock, WaitGroup), an epoch-based garbage collector, and atomic utilities. It solves the core problem of safe, efficient concurrent programming in Rust without requiring users to understand low-level atomics and memory orderings. Monorepo with a root Cargo.toml aggregating workspace members: crossbeam-channel/, crossbeam-deque/, crossbeam-epoch/, crossbeam-queue/, crossbeam-utils/. Root src/ likely re-exports. Each subcrate has its own src/, benches/, and Cargo.toml with independent version control. CI scripts in ci/ run feature-gated tests (ci/check-features.sh). Benchmarks in crossbeam-channel/benchmarks/ compare against external crates (flume, bus, lockfree, Go channels).

Rust systems programmers building concurrent applications like task schedulers, async runtimes, and multi-threaded servers who need battle-tested, lock-free building blocks. Also used by maintainers of other concurrent libraries who want to expose stable, composable synchronization primitives.

Production-ready and actively maintained. The project has dual MIT/Apache-2.0 licensing, requires Rust 1.74+, maintains a CHANGELOG.md and detailed CI/CD in .github/workflows/ (ci.yml, release.yml), and uses careful loom testing and MIRI validation (ci/miri.sh, ci/loom.sh). Monorepo structure with versioned sub-crates (crossbeam-epoch v0.9.17, crossbeam-queue v0.3.10, crossbeam-channel v0.5.10) indicates long-term stability focus.

Low risk for established APIs, but three caveats: (1) epoch-based GC is complex; unsafe code requires careful review (ci/careful.sh exists to check this). (2) Test coverage relies heavily on specialized tools (Loom simulator, MIRI, ThreadSanitizer in ci/san.sh, ci/tsan/) which are required reading. (3) No_std support is partial—alloc feature gate (Cargo.toml) means some APIs unavailable in truly embedded contexts. Maintenance is active (CI badges in README), but core maintainer count should be verified.

The repo structure suggests active polishing: Clippy lints (.clippy.toml), TOML formatting config (.taplo.toml), editor config (.editorconfig), and shell checking (.shellcheckrc) indicate hygiene focus. Dependabot enabled (.github/dependabot.yml) for dependency updates. CHANGELOG.md tracking and release.yml automation suggest regular versioning cadence.

git clone https://github.com/crossbeam-rs/crossbeam.git
cd crossbeam
cargo test --all

For specific subcrate work: cd crossbeam-channel && cargo test. Run CI locally: bash ci/test.sh or bash ci/miri.sh for memory validation.

Daily commands: Development: cargo build, cargo test --all, cargo doc --open. Benchmarking: cd crossbeam-channel/benchmarks && bash run.sh (requires Go installed for go.go comparisons). CI verification: bash ci/test.sh (runs all feature combinations), bash ci/miri.sh (Undefined Behavior detection), bash ci/san.sh (sanitizers).

• Cargo.toml — Root workspace manifest defining all sub-crates (channel, deque, epoch, utils, queue) and their version coordination—every contributor must understand the monorepo structure here.
• crossbeam-channel/src/lib.rs — Main entry point for the channel sub-crate, re-exports all public APIs and defines the select! macro—essential for understanding messaging patterns.
• crossbeam-epoch/src/lib.rs — Core epoch-based memory reclamation implementation; defines Guard, Owned, and Shared abstractions that underpin lock-free data structures across the workspace.
• crossbeam-deque/src/deque.rs — Work-stealing deque implementation demonstrating advanced lock-free patterns using epoch-based reclamation and CAS loops.
• crossbeam-channel/src/select.rs — Core select logic for multi-channel operations; critical for understanding how the select! macro orchestrates waits across heterogeneous channels.
• build-common.rs — Shared build script for conditional compilation (loom, miri, no_atomic) across all sub-crates—essential for understanding platform-specific unsafe code.
• README.md — High-level overview of all modules (Atomics, Data structures, Epoch-based reclamation, Synchronization); every new contributor should read this for scope and API philosophy.

Add a new channel flavor

1. Create a new flavor module (e.g., custom.rs) in crossbeam-channel/src/flavors/ implementing the Flavor trait with send(), recv(), and new_internal_receiver() methods. (crossbeam-channel/src/flavors/custom.rs)
2. Add the variant to the Flavor enum in crossbeam-channel/src/flavors/mod.rs and dispatch in the send_internal() / recv_internal() match arms. (crossbeam-channel/src/flavors/mod.rs)
3. Export a public factory function (e.g., custom()) in crossbeam-channel/src/lib.rs if appropriate. (crossbeam-channel/src/lib.rs)
4. Write integration tests in crossbeam-channel/tests/custom.rs covering send/recv, capacity, and select! integration. (crossbeam-channel/tests/custom.rs)

Add a new lock-free data structure using epoch reclamation

1. Create a new module (e.g., crossbeam-queue/src/skiplist.rs) defining your collection with Guard pins via crossbeam_epoch::pin(). (crossbeam-queue/src/skiplist.rs)
2. Import Owned, Shared, Atomic from crossbeam_epoch and use defer() to queue cleanup tasks on Guard drop. (crossbeam-queue/src/skiplist.rs)
3. Enable the loom feature in Cargo.toml for your crate and add loom-aware atomic wrappers. (crossbeam-queue/Cargo.toml)
4. Write tests in crossbeam-queue/tests/ and add a loom harness in ci/crossbeam-queue-loom.sh following the pattern of ci/crossbeam-epoch-loom.sh. (crossbeam-queue/tests/skiplist.rs)

Extend the select! macro for custom channel types

1. Implement Selectable trait on your channel wrapper (methods: oper(), try_select(), deadline()). (crossbeam-channel/src/lib.rs)
2. Update the select! macro DSL in crossbeam-channel/src/select_macro.rs to recognize your channel's ident pattern (e.g., custom_recv!). (crossbeam-channel/src/select_macro.rs)
3. Add test cases in crossbeam-channel/tests/select_macro.rs demonstrating your custom channel in select! expressions. (crossbeam-channel/tests/select_macro.rs)

Add support for a new platform (no_atomic, WASM, etc.)

1. Update build-common.rs to detect your target platform and set appropriate cfg flags (e.g., cfg(target_arch = "wasm32")). (build-common.rs)
2. Provide fallback implementations in affected crates (e.g., in crossbeam-epoch use parking_lot::Mutex if atomics unavailable). (crossbeam-epoch/build.rs)
3. Add a CI job in .github/workflows/ci.yml to test your target (e.g., cargo test --target=wasm32-unknown-unknown). (.github/workflows/ci.yml)

• Epoch-based reclamation (crossbeam-epoch) — Eliminates garbage collection pauses and enables lock-free algorithms without requiring thread-local bookkeeping overhead; inspired by Java's j.u.c.ConcurrentHashMap epoch design.
• Multi-flavor channel architecture (array/list/zero/tick) — Allows runtime selection of channel behavior (bounded vs. unbounded, synchronous vs. asynchronous) without code branching; enables unified select! interface over heterogeneous sources.
• Work-stealing deque (crossbeam-deque) — Enables efficient task scheduling by allowing threads to steal work from others' queues with minimal contention; critical for CPU-bound workload balancing.
• Loom + Miri testing — Loom performs exhaustive concurrent execution exploration to catch data races; Miri catches undefined behavior in unsafe code—together they provide confidence in lock-free invariants.
• Select! macro with token- — undefined

MIRI overhead: ci/miri.sh will be slow (symbolic execution); expect 10+ minute runtimes. Loom state explosion: ci/crossbeam-epoch-loom.sh explores all thread interleavings; may be slow or hang on some systems—see ci/crossbeam-epoch-loom.sh for timeout settings. no_std caveats: Features are split (std, alloc, bare) across workspace members; passing --no-default-features to one crate doesn't propagate—must be explicit per crate. Unsafe code review burden: Crossbeam-epoch and queue internals are heavily unsafe; code review requires atomics + memory-ordering knowledge. Benchmark dependencies: crossbeam-channel/benchmarks/ requires Go compiler for go.go; run.sh will fail silently if not installed. Feature interaction gotchas: Feature combos tested in ci/check-features.sh—building with only crossbeam-epoch without alloc will compile but no public API exposed (check Cargo.toml feature flags).

• Lock-Free Data Structures — Crossbeam's queues and deques use atomic operations without OS-level locks, enabling true parallel scaling; understanding CAS loops and ABA problems is required to maintain this code.
• Epoch-Based Memory Reclamation (EBMR) — Crossbeam-epoch implements this GC scheme instead of reference counting to avoid expensive atomic increments; it's the most algorithmically complex subsystem and requires deep understanding of Quiescent State-Based Reclamation (QSBR).
• Memory Ordering (Acquire-Release, Sequentially Consistent) — Crossbeam's synchronization primitives rely on precise memory ordering to prevent reordering of critical sections; misunderstanding Rust's std::sync::atomic::Ordering variants can introduce subtle race conditions.
• Work-Stealing Scheduling — Crossbeam-deque provides work-stealing deques used by task schedulers (Tokio, Rayon) to load-balance across threads; understanding LIFO-on-owner / FIFO-on-stealer is key to scheduler design.
• ABA Problem — Lock-free structures in Crossbeam use epoch-based tagging or versioning to defeat ABA issues in Compare-And-Swap loops; this is why crossbeam-epoch exists alongside basic atomics.
• Model Checking with Loom — Crossbeam uses Loom (ci/crossbeam-epoch-loom.sh) to exhaustively verify concurrent algorithms under all possible thread interleavings; understanding how to write Loom-testable code is critical for contributing to epoch or queue logic.
• no_std Compatibility — Crossbeam's feature matrix (std vs. alloc vs. bare) allows use in environments without a standard library; this requires careful conditional compilation and testing across targets (embedded, WASM, RTOS).

• tokio-rs/tokio — Async runtime built on top of Crossbeam primitives; users of Tokio indirectly depend on this repo for thread parking and channel backing
• rayon-rs/rayon — Parallel iterator library that uses crossbeam-deque's work-stealing deques as its core scheduling mechanism
• crossbeam-rs/crossbeam-channel — Separate crate in this workspace providing MPMC channels; can be used independently of the root crossbeam umbrella
• parking_lot-rs/parking_lot — Alternative faster parking primitives; some projects swap parking_lot::Mutex for crossbeam::sync::ShardedLock depending on read-heavy vs. contention profiles
• jeremyletang/stm32-rtic — RTIC RTOS framework used on embedded Rust systems where crossbeam's epoch GC and channels are too heavy; crossbeam-utils' no_std AtomicCell is sometimes used instead

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive benchmarks for crossbeam-epoch memory reclamation

The crossbeam-channel crate has extensive benchmarks in crossbeam-channel/benchmarks/ comparing against competing libraries (flume, futures-channel, lockfree, etc.), but crossbeam-epoch lacks similar comparative benchmarks. Given that epoch-based reclamation is a core differentiator of Crossbeam, adding benchmarks comparing epoch performance against alternatives (hazard pointers, quiescent-state-based RCU) would help contributors understand performance characteristics and catch regressions.

• [ ] Create crossbeam-epoch/benchmarks/ directory structure (similar to crossbeam-channel/benchmarks/)
• [ ] Add benchmark comparing epoch-based reclamation overhead vs. hazard pointer implementations
• [ ] Add benchmark measuring pinning/unpinning overhead under various contention levels
• [ ] Update ci/ test scripts to run epoch benchmarks in CI pipeline
• [ ] Document results in crossbeam-epoch/README.md

Add platform-specific tests for no_std environments in CI

The repo supports no_std (as evidenced by categories and AtomicCell being marked no_std), and ci/no_atomic.sh exists, but there's no dedicated CI workflow testing no_std for all crates across different platforms (embedded targets, wasm, etc.). Current ci/test.sh and ci/miri.sh don't explicitly validate no_std compatibility. Adding a .github/workflows/no-std.yml would catch regressions early.

• [ ] Create .github/workflows/no-std.yml CI workflow
• [ ] Add matrix testing for targets like thumbv7em-none-eabihf, wasm32-unknown-unknown, riscv64gc-unknown-none-elf
• [ ] Test each crate with default-features=false to verify no_std support
• [ ] Ensure alloc feature works independently of std feature
• [ ] Document no_std compatibility status for each crate in respective README files

Add property-based testing with proptest for select! macro edge cases

The select! macro in crossbeam-channel/src/select_macro.rs is complex and handles numerous edge cases (multiple channels, timeouts, deadlock scenarios). While crossbeam-channel/tests/ has some tests, there are no property-based tests generating random combinations of channel configurations, operations, and timing scenarios. This would improve robustness of the macro implementation.

• [ ] Add proptest dependency to crossbeam-channel/Cargo.toml dev-dependencies
• [ ] Create crossbeam-channel/tests/prop_select.rs with property strategies for: channel counts, operation sequences, timeout values, thread counts
• [ ] Test invariants like: 'select always returns exactly one result', 'no messages are lost', 'operations are linearizable'
• [ ] Add regression tests for any edge cases found during property testing
• [ ] Document property testing approach in crossbeam-channel/README.md testing section

• Add missing documentation examples to crossbeam-queue/src/seg_queue.rs and crossbeam-queue/src/array_queue.rs showing unbounded vs. bounded trade-offs—existing README.md hints at this but no inline rustdoc examples.
• Expand ci/test.sh to validate all feature permutations run on WASM targets (wasm32-unknown-unknown)—current CI only tests x86_64-unknown-linux-gnu (see .github/workflows/ci.yml); no_std+alloc should work on WASM but untested.
• Create a runnable example in crossbeam-channel/examples/ demonstrating bounded vs. unbounded channels under backpressure (similar to stopwatch.rs and fibonacci.rs)—docs mention ArrayQueue and SegQueue but no channel example shows queue selection strategy.

The Crossbeam repository demonstrates strong security practices overall. It is a well-maintained concurrent programming library with dual MIT/Apache 2.0 licensing. The codebase shows good security fundamentals: (1) No hardcoded secrets or credentials found in file structure, (2) No obvious injection vulnerabilities based on file naming and structure, (3) No exposed ports or dangerous configurations visible, (4) No Docker misconfigurations detected, (5) Uses modern Rust edition (2021) with MSRV of 1.74, (6) Dependencies are workspace-managed with explicit version pinning. The main concern is the truncated Cargo.toml in the provided content, though this appears to be a data delivery issue rather than an actual codebase vulnerability. The library's focus on thread-safe concurrent operations with atomic primitives and lock-free data structures aligns with security best practices for concurrent programming in Rust.

• Low · Incomplete Cargo.toml dependency specification — Cargo.toml. The Cargo.toml file appears to be truncated in the provided content. The last dependency entry for 'crossbeam-utils' is incomplete (shows 'versi' instead of complete version specification). This could mask potential dependency vulnerabilities if the actual file has issues. Fix: Verify the complete Cargo.toml file is properly formatted and all dependencies have complete version specifications. Run 'cargo tree' to verify all dependencies are correctly resolved.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.