Page MenuHomePhabricator

Possibly fix issue with subpriority recursion
ClosedPublic

Authored by epriestley on Apr 22 2015, 11:13 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 29, 4:16 AM
Unknown Object (File)
Fri, Mar 29, 4:05 AM
Unknown Object (File)
Feb 10 2024, 3:03 PM
Unknown Object (File)
Jan 28 2024, 1:25 PM
Unknown Object (File)
Jan 26 2024, 3:25 PM
Unknown Object (File)
Jan 17 2024, 4:05 AM
Unknown Object (File)
Jan 16 2024, 4:53 PM
Unknown Object (File)
Dec 24 2023, 12:54 PM
Subscribers

Details

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?

Diff Detail

Repository
rP Phabricator
Branch
repri1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 5448
Build 5466: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

epriestley retitled this revision from to Possibly fix issue with subpriority recursion.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
btrahan edited edge metadata.
This revision is now accepted and ready to land.Apr 22 2015, 11:47 PM
This revision was automatically updated to reflect the committed changes.