Homec4science

Possibly fix issue with subpriority recursion

Authored by epriestley <git@epriestley.com> on Apr 23 2015, 01:48.

Description

Possibly fix issue with subpriority recursion

Summary:
Ref T7664. Currently, when spreading subpriorities we may recurse deeply in certain conditions. Make sure we never recurse more than one level.

To try to mitigate issues with floating point precision, be more aggressive about selecting tasks to reorder.

I wasn't really able to come up with a realistic test case here, and the test cases I found which sort of approximated the behavior took way too long to generate data to actually commit.

This approach is inherently somewhat fragile but hopefully this is approximately good enough. We don't have a durable storage engine which can meaningfully represent double-linked lists right now.

Test Plan:

  • Wrote some (slow) tests which kind of approximately hit the issue.
  • Verified they maxed out at stack depth 2 after the change.
  • Unit tests still pass.
  • Dragged some tasks around.
  • Couldn't come up with any pathological issues here by thinking about it?

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7664

Differential Revision: https://secure.phabricator.com/D12511

Details

Committed
epriestley <git@epriestley.com>Apr 23 2015, 01:48
Pushed
aubortJan 31 2017, 17:16
Parents
rPHb5b8d0982ca6: Make "Current Application" imply "Open documents in..."
Branches
Unknown
Tags
Unknown

Event Timeline

epriestley <git@epriestley.com> committed rPHf044c1e999b1: Possibly fix issue with subpriority recursion (authored by epriestley <git@epriestley.com>).Apr 23 2015, 01:48