[gaborbernat]

Two async locks ignored their callers while waiting. The async read-write wrappers ignored cancellation while another process held the lock. A thread-local AsyncFileLock shared by threads with their own event loops deadlocked on its first contention. ⏳ This PR lets a cancelled acquire stop its backend wait and gives each thread-local lock context its own transition gate (the queue that orders one lock's acquire and release calls). It builds on #838, which records the wrappers' sync-lock hold under a task owner.

Cancellation waited for the other process to let go

AsyncReadWriteLock and AsyncSoftReadWriteLock handed the whole contended wait to one executor call. Since #652, copied to the soft wrapper in #686, a CancelledError made _run_acquire drain that call before rolling it back. Nothing told the call to stop. For SQLite it was one busy_timeout wait of about 23 days at timeout=-1; for the soft lock an open-ended poll loop. So asyncio.timeout() or task.cancel(), which the how-to recommends for bounding the wait, took effect only when the holder released. asyncio.run() needed several Ctrl-C presses to exit. With a finite lock timeout the drained call ended in Timeout, which replaced the cancellation, so a background task cancelled at shutdown kept retrying.

sequenceDiagram
    participant T as task
    participant W as executor worker
    participant S as SQLite / lock files
    participant P as another process
    P->>S: holds the write lock
    T->>W: acquire (one call)
    W->>S: wait
    T-->>T: asyncio.timeout(1) fires: CancelledError
    rect rgb(255, 214, 214)
        Note over T,S: before: drain the call. It ends when P releases, then Timeout or CancelledError
    end
    rect rgb(216, 243, 220)
        Note over T,S: after: set the abandon flag. The worker gives up at its next slice, the task sees CancelledError
        T->>W: abandoned.set()
        W->>S: busy_timeout slice ends, database is locked
        W-->>T: Timeout → re-raised as the cancellation
    end

Loading

The wrapper now passes an abandon flag into the sync-lock acquire and sets it on cancellation. ReadWriteLock waits for SQLite in bounded busy-timeout slices on the same connection, retrying BEGIN while SQLite reports "database is locked". A read's deferred BEGIN succeeds before its SELECT takes the shared lock, so the retry rolls that back first. _acquire_thread_lock() takes the lock's in-process lock in the same slices. SoftReadWriteLock checks the flag between polls, so its existing rollback withdraws the published claim. A wait that gave up this way ends in a Timeout the wrapper re-raises as the caller's cancellation. The wrapper still rolls back an acquire that won the race meanwhile. Slicing inside the sync lock keeps one connection open for the wait; retrying the whole acquire from the wrapper would reopen it ten times a second. Synchronous callers keep the single uninterrupted wait.

#840 splits a threaded process's wait into 50 ms attempts for the same _acquire. Whichever of the two lands second has to pass holder and cancel_check into each attempt and ask cancel_check() between attempts, because a 50 ms attempt is shorter than the 100 ms slice and does not install the check on its own. The retry loop in _acquire therefore also checks for cancellation after each attempt that times out, and gives up when the caller has abandoned the acquire.

A thread-local async lock deadlocked between its threads

BaseAsyncFileLock created one transition gate per instance in #652. thread_local=True gives each thread its own lock state through threading.local. A thread whose own context held nothing took the gate and kept it for its whole poll loop. The thread that held the lock then queued on the same gate inside release(). With the default timeout=-1 neither thread ever returned and the lock file stayed held. With a finite timeout every wait ended in Timeout, however early the holder finished. Any other process holding the lock file while both threads called acquire() set the order up by itself. The sync BaseFileLock skips its gate for thread-local instances; the async side did not.

sequenceDiagram
    participant A as thread 1 (holds the lock)
    participant G as gate
    participant B as thread 2 (own context, unlocked)
    rect rgb(255, 214, 214)
        Note over A,B: before: one gate per instance
        B->>G: acquire(): take the gate, poll while A holds
        A->>G: release(): queue behind B
        Note over A,B: each waits for the other
    end
    rect rgb(216, 243, 220)
        Note over A,B: after: one gate per context
        B->>B: acquire(): own gate, poll
        A->>A: release(): own gate, unlock at once
        B->>B: next poll takes the lock
    end

Loading

The gate moved into AsyncFileLockContext. AsyncThreadLocalFileContext already delegates every dataclass field to the calling thread's context, so a thread-local lock gets one gate per thread and a shared lock keeps one per instance. Skipping the gate for thread-local instances, as the sync lock does, would not do: several tasks of one thread still share that thread's context and need the serialization.

Behavior changes

A cancelled AsyncReadWriteLock or AsyncSoftReadWriteLock acquire that was waiting on another process now ends with the caller's CancelledError within about 0.1 s (one poll interval for the soft lock). It used to end in Timeout, or in a cancellation delayed until the holder released. An async writer waiting for readers now holds SQLite's PENDING lock only within a slice and gives it up between slices. A reader in another process can therefore enter between two slices where it used to wait behind the writer.