commit 2887806f33898209dc3ecec343b59820f9c0f801
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue Feb 3 16:40:54 2026 +0000

    pacer: fix deadlock between pacer token and --max-connections
    
    It was possible in the presence of --max-connections and recursive
    calls to the pacer to deadlock it leaving all connections waiting on
    either a max connection token or a pacer token.
    
    This fixes the problem by making sure we return the pacer token on
    schedule if we take it.
    
    This also short circuits the pacer token if sleepTime is 0.

commit 9ed4295e34445c389800159b3bd0a5d466fbeb54
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Sat Aug 30 11:06:40 2025 +0100

    pacer: fix deadlock with --max-connections
    
    If the pacer was used recursively and --max-connections was in use
    then it could deadlock if all the connections were in use at the time
    of recursive call (likely).
    
    This affected the azureblob backend because when it receives an
    InvalidBlockOrBlob error it attempts to clear the condition before
    retrying. This in turn involves recursively calling the pacer.
    
    This fixes the problem by skipping the --max-connections check if the
    pacer is called recursively.
    
    The recursive detection is done by stack inspection which isn't ideal,
    but the alternative would be to add ctx to all >1,000 pacer calls. The
    benchmark reveals stack inspection takes about 55nS per stack level so
    it is relatively cheap.

commit 2fa1a52f22cf052d7ab0a9ab313b203bed9b39df
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Sat Aug 30 10:29:45 2025 +0100

    Revert "azureblob: fix deadlock with --max-connections with InvalidBlockOrBlob errors"
    
    This reverts commit 0c1902cc6037d81eaf95e931172879517a25d529.
    
    This turns out not to be sufficient so we need a better approach
