Page MenuHomePhabricator

Streamline handling of Futures and PIDs in daemons

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



Ref T13555. Currently, the daemon future may resolve into a failure state immediately inside "start()", and not have a valid PID when we read it.

Instead, read PIDs from the current active future in all cases, using "hasPID()" to test for the presence of a valid PID.

Since we don't query the PID immediately, we no longer need to explicitly start the future.

Also fix an issue where the same future could be added to the overseer pool more than once if it threw on "resolve()". In general:

  • Before we "resolve()" a future, detach it from the DaemonHandle: we're always done with it.
  • Catch exceptions on resolution and treat them the same way as subprocess resolution errors. These aren't common, but are possible in the general case.
  • Have DaemonHandle add futures to the future pool directly when they're created.
Test Plan
  • Ran daemons with intentional subprocess creation failures, saw clean recovery.
  • Ran daemons with intentional resolution exceptions, saw clean recovery.

Diff Detail

rP Phabricator
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:40 PM
epriestley requested review of this revision.Thu, Jul 23, 5:41 PM
epriestley updated this revision to Diff 50978.Thu, Jul 23, 5:42 PM
  • Use "$caught", not "$ex", to make the code less fragile.
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.