`timeout`

limit보다 오래 걸리는 개별 pull을 TimeoutException으로 실패시킵니다.

FxAsyncIterable<A> timeoutAsync<A>(Duration limit, FxAsyncIterable<A> iterable) FxAsync<T> FxAsync<T>.timeout(Duration limit) // chain (async)

강의

파이프라인의 반응성은 가장 느린 await만큼만 좋을 수 있습니다. timeout(limit)은 거기에 한도를 겁니다. 각 pull — 상류 연산자를 몇 개 거치든, 항목 하나를 만들어 내는 작업 — 은 limit 안에 끝나야 하고, 그러지 못하면 그 pull은 TimeoutException으로 실패합니다. 빠른 항목은 건드리지 않으며, 이 연산자 자체가 지연을 더하지도 않습니다.

정확히 짚어 둘 만한 pull 모델의 의미론입니다. 이 한도가 재는 것은 요청부터 항목까지의 시간 — 하류가 요청한 순간부터 항목이 도착하는 순간까지입니다. 항목 사이의 간격은 재지 않고(요청이 없으면 간격도 없습니다), 파이프라인 전체를 제한하지도 않습니다 (그것은 종단에 거는 Future.timeout의 몫입니다: fxAsync(…).toList().timeout(…)). RxDart의 timeout은 push 스트림에서 이벤트 사이 간격을 감시합니다 — 이름은 같지만 반대편에서 재는 것입니다.

Dart 고유의 추가 기능입니다(FxTS에는 대응물이 없습니다). 병렬 안전합니다. concurrent(n) 아래에서는 겹쳐 진행되는 각 pull이 자기만의 타이머를 갖고 있으므로, 다소 느린 항목 n개가 겹쳐도 각각 개별적으로 통과합니다. retry와 짝을 이룹니다 — timeout은 "멈춰 있음"을 "실패함"으로 바꾸고, retry는 "실패함"을 "다시 시도함"으로 바꿉니다.

데모 1 · 멈춤 잡아내기

데모 2 · 파이프라인이 아니라 pull 단위

직접 해 보기

연습: 느린 피드에 한도를 걸고, 그다음 복구해 보세요.

관련 항목: retry — 타임아웃이 발생한 뒤 할 일 · concurrent — 겹치는 pull은 독립적으로 타임아웃됨 · 타입 있는 에러 — TimeoutException을 값으로 잡기