[Webkit-unassigned] [Bug 83951] New: [Chromium] CCLayerTreeHostTest racyness from beginTest()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=83951

           Summary: [Chromium] CCLayerTreeHostTest racyness from
                    beginTest()
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: sievers at chromium.org
                CC: jamesr at chromium.org, enne at google.com,
                    nduca at chromium.org, danakj at chromium.org


For example, putting a sleep() before the call to postSetNeedsCommitToMainThread() in CCLayerTreeHostTestScrollMultipleRedraw's beginTest() causes it to fail.
I think it's because setScrollable() having been called earlier races with the second 'needs commit' task, while the test expects a certain number of commits (and even a draw without commit).

Also some tests might do other modifications to the tree that implicitly cause a 'needs commit' to be posted.

Why do tests use postSetNeeds*ToMainThread() inside beginTest() which already runs on the main thread. Does that cause more potential for races?

What if a test does this

void beginTest()
{
   // modify tree, causes set needs commit and eventually triggers beginCommitOnCCThread()
   //...
A: // set some other internal state X
}

virtual void beginCommitOnCCThread()
{
B:  // does something that relies on state X
}

Can A race with B?

Maybe we need some safety barriers in the test harness for beginTest().

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.