Page MenuHomePhabricator

Give Futures clearer start/end and exception semantics
ClosedPublic

Authored by epriestley on Jul 23 2020, 5:07 PM.
Tags
None
Referenced Files
F15384013: D21423.id50974.diff
Fri, Mar 14, 6:32 PM
F15345870: D21423.id50976.diff
Mon, Mar 10, 1:04 PM
F15333363: D21423.id50976.diff
Sat, Mar 8, 2:03 AM
F15332731: D21423.diff
Fri, Mar 7, 7:44 PM
Unknown Object (File)
Feb 18 2025, 2:21 AM
Unknown Object (File)
Feb 10 2025, 3:06 AM
Unknown Object (File)
Jan 28 2025, 5:21 PM
Unknown Object (File)
Jan 28 2025, 5:40 AM
Subscribers
None

Details

Summary

Ref T13555. Currently:

  • If an exception is raised in "start()", the exception state is not set on the future.
  • Futures do not always call "startFuture()" before starting, and do not always call "endFuture()" once they become resolvable.
  • If you start an ExecFuture which immediately fails and then call "getPID()" on it, you get an unclear exception.

Simplify these behaviors:

  • In FutureIterator, only start futures which have not already started.
  • When starting a future on any pathway, run start code.
  • When a future becomes resolvable on any pathway, run end code.
  • Raise a more clear exception when calling "getPID()" on a future with no subprocess.
Test Plan

Faked a failing subprocess with "$proc = null", ran "bin/phd debug taskmaster" etc. Got clearer errors and more consistent future lifecycle workflows.

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable