Normalize quoted fallback keywords by oferchen · Pull Request #1935 · oferchen/rsync

oferchen · 2025-11-04T08:18:28Z

Summary

trim fallback keyword comparisons after removing quotes so whitespace-padded values still map to auto/disabled behaviour
add regression tests covering whitespace-padded keywords and quoted paths with interior spaces

Testing

cargo test -p rsync-core fallback

https://chatgpt.com/codex/tasks/task_e_6909b4cdcbd483239ee3e4713579f476

…feature (#1934) (#3524) Adds docs/audits/daemon-async-listener-rfc.md sketching a feature-gated tokio-based async accept loop for the daemon. The accept loop and greeting/module-select phase run on the tokio runtime; the transfer hot path stays synchronous behind a spawn_blocking hand-off, keeping tokio scoped to the daemon crate per the #1779 / #1818 policy. Design only - implementation lands in #1935.

) Specifies a hybrid model where a tokio async accept loop hands off accepted connections to a fixed-size pool of synchronous worker threads via a bounded channel. Transfer state machine and wire format are unchanged; the design only replaces the accept-and-dispatch layer. Tracking #1674. References #1591 (async-channel abstraction), #1934/#1935 (async-daemon feature gate), #2052 (TLS termination).

Defines the empirical benchmark harness, workloads (100 / 1k / 10k concurrent clients), metrics, soft-limit triggers, comparison oracle against upstream rsync 3.4.1, and the decision criteria that gate the async listener migration tracked under #1935. Frames the active-counter fix from the parent audit (#1673, PR #3705) as a strict precondition. Tracking: oc-rsync task #1933.

) Defines the empirical benchmark harness, workloads (100 / 1k / 10k concurrent clients), metrics, soft-limit triggers, comparison oracle against upstream rsync 3.4.1, and the decision criteria that gate the async listener migration tracked under #1935. Frames the active-counter fix from the parent audit (#1673, PR #3705) as a strict precondition. Tracking: oc-rsync task #1933.

Concrete plan for replacing the synchronous accept loop with a Tokio listener bridged to the sync transfer worker via spawn_blocking. Gated behind a new async-daemon Cargo feature. Cross-references #1934 (accepted RFC) and #1751 (async migration roadmap).

…#3891) Slim runnable plan complementing the broader benchmark plan. Specifies the minimum harness needed to land first measured numbers on Linux loopback at 100/1K/10K concurrent rsync:// pulls so #1934 RFC and #1935 async-listener work can compare sync vs async paths against quantified sync-baseline ttfb, completion p99, peak RSS, and thread count.

…c daemon (#1751) (#3893) Designs the bridge between the tokio-driven async daemon (#1934/#1935) and rayon-dispatched CPU work (checksums, delta apply, parallel stat). Recommends a `rayon_bridge` helper in `crates/transfer/src/async_compat.rs` using `tokio::task::spawn_blocking` with a threshold short-circuit, and discusses the dedicated-pool + `block_in_place` alternative plus risks (double-spawn, panic propagation, cancellation, oversubscription).

#3895) Replace the thread-per-connection audit with a focused 5-section brief covering the accept loop in crates/daemon/src/daemon/sections/server_runtime/accept_loop.rs, the per-thread stack and per-session memory ceiling, the fork-vs-thread trade vs upstream rsyncd, slowloris and lock-contention failure modes, and the migration path through tokio listener (#1934/#1935), daemon-level max_connections, and bounded worker pools.

Expand the placeholder async migration plan into a comprehensive, opinionated design covering: current synchronous threading model per subsystem, per-subsystem cost/benefit, a phased incremental adoption strategy, tokio runtime choice with rejected alternatives, sync/async bridge patterns, backward-compat strategy, risk register, and open questions. Cross-references existing async-related tasks (#1367, #1411, #1591, #1593, #1595, #1674, #1751, #1779, #1780, #1782, #1796, #1797, #1805, #1806, #1889, #1890, #1891, #1892, #1934, #1935, #2136) and related design notes so future planners have a single anchor.

…1751) (#4196) Document the canonical sync/async bridge between rayon-dispatched CPU work and the tokio runtime that will host the async daemon listener landing in #1935. Inventories 30 rayon call sites reachable from the daemon code paths, fixes the bridge signature, sizing recipe for both pools, anti-patterns to forbid in review, migration order keyed to phase 2 of the async migration plan, and a test strategy that does not require the async daemon to exist yet.

…2136) (#4210) Reframe the actor-pattern evaluation around supervised tokio tasks (Erlang/Akka style with bounded mailboxes and a supervisor that restarts crashed actors) to match the post-async-migration target the migration plan commits us to. The recommendation stays: reject the actor reshape for the production hot path because rsync's wire protocol is sequential with no resume primitive, so supervisor restart is a no-op; adopt the actor surface only for multi-host fan-out and fault-injection tests, behind --features async-pipeline. Cross-references #4186 (async migration plan), #4196 (spawn_blocking bridge), #2134 (type-state for protocol phases, recently merged), and #1935 (async daemon listener).

…4226) Captures the wrapper-level design for swapping the SSH subprocess stdio onto tokio::process::Child stdio. Records why tokio::process is preferred over a raw AsyncFd construction, what async actually buys beyond today's thread-per-half overlap (thread elimination, collapsed stderr drain and connect watchdog), the parallel AsyncSshConnection surface, a sync-vs-async bench matrix anchored on the 1 MB/s emulated link from #1889, and a recommendation to defer the implementation until the async daemon (#1935) lands so runtime ownership is settled first.

Add a focused evaluation of async runtime options for the daemon accept loop. Compares tokio against async-std and the existing thread-per-connection model, and records the decision to adopt tokio with the rt-multi-thread flavour under the existing async feature gate. The doc complements the implementation plan in #1935 and the benchmark plan in #1933 rather than restating either. It covers maintenance posture, feature parity, ecosystem alignment, the case for staying threaded, the case for tokio, migration cost, trigger conditions, and a five-step adoption sequence.

) (#4278) Adds the implementation skeleton for the hybrid daemon listener accepted in the runtime-choice ADR: a tokio multi-thread runtime drives TcpListener::accept while each connection is handed to the existing synchronous worker via spawn_blocking. Default builds remain tokio-free. - New `async-daemon` cargo feature gates the entire path. - `crates/daemon/src/async_listener.rs` exposes `run_hybrid_listener`, taking an `Arc<dyn Fn>` sync worker and a shutdown flag. Unit tests bind on an ephemeral port and confirm accept-and-dispatch plus prompt shutdown work end-to-end. - `daemon::run_async_daemon` wires the listener to the existing daemon config and signal-flag plumbing. The per-connection worker is a documented stub; production wiring to the sync session handler ships in the follow-up tracked under #1935 once the trigger conditions from `docs/design/daemon-async-runtime-choice.md` are met. - Tokio features extended with `rt-multi-thread` and `macros` so the new builder path compiles alongside the existing `async` feature.

… (#4285) Audits whether prerequisites for #1876 have landed and proposes splitting the work into reviewable subtasks (#1876-a through e). - #1874 (shared ring + POLL_ADD) shipped via PR #3553. - #1937 (session ring pool) shipped via PR #4275. - #1935 (hybrid tokio listener) shipped via PR #4278. - No io_uring task carries id #1875; the original dependency note most plausibly meant the session-pool and listener work above. Missing surface enumerated: pooled-ring constructors on the socket adapters, daemon plumbing for SessionRingPool, sync and async worker swaps, IORING_OP_LINK_TIMEOUT integration, and async-cancel discipline. Trigger conditions (kernel >= 5.6, io_uring feature, opt-in flag) and a five-step implementation plan included.