Name what each of the three request paths skips
Test / test (22) (pull_request) Successful in 32s
Test / test (24) (pull_request) Successful in 32s
Mirror / push (push) Has been cancelled
Test / test (26) (pull_request) Successful in 32s
Test / lint (pull_request) Successful in 23s
Test / test (18) (pull_request) Successful in 32s
Test / test (20) (pull_request) Successful in 32s
Test / test (22) (pull_request) Successful in 32s
Test / test (24) (pull_request) Successful in 32s
Mirror / push (push) Has been cancelled
Test / test (26) (pull_request) Successful in 32s
Test / lint (pull_request) Successful in 23s
Test / test (18) (pull_request) Successful in 32s
Test / test (20) (pull_request) Successful in 32s
This commit is contained in:
+1
-1
@@ -772,7 +772,7 @@ rule and an index of the titles below.
|
||||
`OutgoingRequests.canCarry()` reads it rather than `closed`. The gate is told what happened and
|
||||
never reads back into the session: a collaborator that has to ask does not own its decision, which
|
||||
is how the first cut ended up answering the same question two different ways at admit and at
|
||||
release. The retry in `carry()` asks `gate.awaitsNextLink()` rather than `canCarry()`, which also
|
||||
release. The retry in `requestPastDrain()` asks `gate.awaitsNextLink()` rather than `canCarry()`, which also
|
||||
reads the socket: a loop condition the gate does not gate on spins against a gate that admits it
|
||||
straight back.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user