[Webkit-unassigned] [Bug 186455] New: [Win] Remove RunLoopWin and WorkQueueWin

[bugzilla-daemon at webkit.org]

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

            Bug ID: 186455
           Summary: [Win] Remove RunLoopWin and WorkQueueWin
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: utatane.tea at gmail.com

Why do we have platform-dependent RunLoop? The answer is that we sometimes want to integrate our RunLoop into the existing platform RunLoop, which is driven by the system or main function of the application.
For example, RunLoopCF uses CFRunLoopGetCurrent() to drive the *current* RunLoop, which is driven by the application too.
And RunLoopGLib is the same: It retrieves the *default* RunLoop for the current application, which is shared by the glib application too.

On the other hand, Windows RunLoop implementation is different. It creates a special window handle per RunLoop by CreateWindow. And we use the message loop of this window handle.
But this window handle is not shared by the application. This window handle is only used by RunLoop. We do not have the way to post a message to this window handle without interacting to this RunLoopWin.

So, do we really need to have RunLoopWin implementation? Why not use RunLoopGeneric in Windows instead?

This patch removes RunLoopWin, and WorkQueueWin. Windows start using RunLoopGeneric and WorkQueueGeneric.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180609/23208829/attachment.html>