scverse / scverse/rustar-aligner
deps: noodles 0.113 -> 0.115 and noodles-bgzf 0.49 -> 0.51 (local thread pools, with_worker_count)
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 75
- Forks
- 7
- Avg merge
- 8m
- Merged PRs (30d)
- 1
Description
noodles moved fast in the last two weeks and the pins here are two minors behind.
| Crate | Pinned | Latest | Released |
|---|---|---|---|
noodles |
0.113 |
0.115.0 |
2026-08-03 |
noodles-bgzf |
0.49 |
0.51.0 |
2026-08-03 |
Pre-1.0, so minors are breaking by convention: this needs reading, not a blind bump.
Why bgzf 0.50 / 0.51 specifically matter here
- 0.50 — multithreaded readers and writers moved off rayon's global pool onto exclusive local
pools, and the deprecatedwith_worker_countmethods came back as the supported way to size them. - 0.51 — worker count is now synced to the number of managed buffers instead of rayon's global
pool, so merely constructing one no longer initialises that pool.
This codebase leans on rayon for alignment (src/lib.rs and friends). A BGZF component that
quietly borrows the global rayon pool competes with the align workers for the same threads; a
component with its own sized pool does not. That is the interesting part of the upgrade.
The adjacent opportunity
src/io/bam.rs:48 builds a plain single-threaded bgzf::io::Writer for every BAM sink
(:60, :374). BAM output is therefore serialised behind one compressor while alignment runs on N
threads. With 0.50+ the multithreaded writer is usable with an explicit, non-global worker count,
which is exactly the shape needed here.
Caveat that must be checked, not assumed: BGZF block boundaries and therefore output bytes can
depend on the writer's buffering, so a multithreaded writer must be shown to produce a
byte-identical file (or a documented, deliberate change) at every worker count.
Checklist
- Read the noodles changelogs 0.113 → 0.115 for
fastq/sam/bam, note breaking changes - Bump
noodlesandnoodles-bgzfin separate commits from any behaviour change - Full test suite + the faithfulness benchmark, before/after
- Separately evaluate the multithreaded BGZF writer with an explicit
with_worker_count - Prove BAM bytes identical across worker counts, or document the change
- Also on the table while here:
bstr1.13,rustc-hash2.1.3,memmap20.9.11 (all
compatible with existing ranges);dashmap7 is a release candidate, stay on 6
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the noodles 0.113→0.115 changelogs, then inspect rayon usage in src/lib.rs and the BGZF writers at src/io/bam.rs:48, :60, and :374. Run the full test suite and faithfulness benchmark before and after; done means the upgrades work and any multithreaded writer produces byte-identical BAM output across worker counts or documents the deliberate change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- bioinformatics, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100