Page MenuHomePhabricator

Streamline handling of Futures and PIDs in daemons
ClosedPublic

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

Details

Summary

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

Repository
rP Phabricator
Branch
pid2
Lint
Lint OK
Unit
Unit Tests OK
Build Status
Buildable 24798
Build 34212: Run Core Tests
Build 34211: arc lint + arc unit

Event Timeline

  • Use "$caught", not "$ex", to make the code less fragile.
This revision was not accepted when it landed; it landed in state Needs Review.Jul 23 2020, 6:22 PM
This revision was automatically updated to reflect the committed changes.