Page MenuHomePhabricator

Give Futures clearer start/end and exception semantics

Authored by epriestley on Thu, Jul 23, 5:07 PM.



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

rARC Arcanist
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Thu, Jul 23, 5:07 PM
epriestley requested review of this revision.Thu, Jul 23, 5:08 PM
epriestley updated this revision to Diff 50976.Thu, Jul 23, 5:17 PM
  • Add "ExecFuture->hasPID()" to simplify reading PID information.
This revision was not accepted when it landed; it landed in state Needs Review.Thu, Jul 23, 6:22 PM
This revision was automatically updated to reflect the committed changes.