Page MenuHomePhabricator

Introduce "FuturePool" to make it easier to manage an ongoing pool of futures
ClosedPublic

Authored by epriestley on Apr 3 2020, 6:56 PM.
Tags
None
Referenced Files
F18388229: D21053.diff
Fri, Aug 29, 4:08 AM
F18149837: D21053.id50159.diff
Thu, Aug 14, 5:35 PM
F18111977: D21053.id.diff
Tue, Aug 12, 3:45 PM
F18110746: D21053.diff
Mon, Aug 11, 11:27 PM
F18100936: D21053.diff
Sat, Aug 9, 12:11 PM
F17803502: D21053.id50159.diff
Jul 25 2025, 10:15 AM
Unknown Object (File)
Jul 1 2025, 9:11 PM
Unknown Object (File)
Apr 27 2025, 4:11 PM
Subscribers
None

Details

Summary

Ref T11968. "FutureIterator" recently became non-rewindable, and starting a Future twice is now an error.

This complicates a handful of use cases where a mostly-constant pool of futures is maintained over a long period of time, notably in daemon overseers and repository pull daemons.

They previously relied on being able to do "new FutureIterator($futures)" to continue resolution of a list of futures from any state. This no longer works quite like it used to, since Futures generally may not belong to more than one iterator now (and this property is desirable).

Introduce "FuturePool", which maintains exactly one iterator but manages the small amount of glue around adding and removing Futures from it, destroying it if the pool empties, and rebuilding it if the pool fills.

Test Plan

See next change, which makes use of this.

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable