Summary: | [CoordGraphics] CompositingRunLoop assumes a WorkQueue has a RunLoop | ||
---|---|---|---|
Product: | WebKit | Reporter: | Don Olmstead <don.olmstead> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | cgarcia, Hironori.Fujii, mcatanzaro, ysuzuki, zan |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=195208 | ||
Bug Depends on: | |||
Bug Blocks: | 186364 |
Description
Don Olmstead
2018-06-08 13:54:55 PDT
I don't think WorkQueue should expose RunLoop in its member function since it's implementation detail. If handling RunLoop is required, it means that WorkQueue abstraction is too high to use there. CompositingRunLoop should use RunLoop instead of WorkQueue I think. We have two options here, either use our own thread with a run loop, or keep using a work queue, but making the timer creation platform specific (I guess in windows you could add a WorkQueue::timerQueue() similar to dispatchQueue() used by cocoa and runLoop() used by glib and generic) and create the timer with CreateTimerQueueTimer(). This will be fixed in bug #195208 *** This bug has been marked as a duplicate of bug 195208 *** |