Page MenuHomePhabricator

Streamline handling of Futures and PIDs in daemons

Authored by epriestley on Jul 23 2020, 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
Lint Not Applicable
Tests Not Applicable

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.
jmeador added inline comments.

canResolve doesn't seem to exist anywhere in the codebase... but my daemons work fine. What gives?

The Future stuff is used on both the client and server, so it lives in Arcanist rather than Phabricator. The method definition should be here:$253