You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Broque Thomas 2c19d7d1f2 Per-source lock sharding on the engine ... Per JohnBaumb: the single state_lock serialized progress callbacks across every source. Pre-refactor each client owned its own download lock, so Deezer / YouTube / Tidal workers never blocked each other. Multi-source concurrent downloads under the unified lock fought for the same RLock on every progress update. Replaced the engine-wide state_lock with per-source RLocks. Each source gets its own lock, lazily created via _source_lock() on first use (meta-lock guards the create-race). All record mutations (add/update/update_unless_state/remove/get/iter) take only that source's lock — Deezer progress updates no longer block Tidal writes. Cancelled-preserve semantics still hold because cancel + worker terminal write target the same source, so they share that source's lock. New test pins lock independence: holding source-A's lock from one thread does not block a write on source-B from another.		3 weeks ago
..
__init__.py	E1: Add RateLimitPolicy declaration mechanism	3 weeks ago
engine.py	Per-source lock sharding on the engine	3 weeks ago
rate_limit.py	E1: Add RateLimitPolicy declaration mechanism	3 weeks ago
worker.py	Per-source lock sharding on the engine	3 weeks ago