Foundation: unmask Windows events on the main RunLoop #4759
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
CC: @parkera |
|
@swift-ci please test |
|
Please test with following PRs: @swift-ci please test Windows platform |
|
CC: @iCharlesHu @itingliu |
When processing events on the main runloop, we should unmask the Windows message pump events. If we do not unmask these events, the main RunLoop is unable to process the UI events and the user has no mechanism for integrating the Windows message pump events into the run loop. This is a slightly restrictive compromise to enable the use of RunLoop on Windows for pumping a UI application. Because CoreFoundation is not a supported API surface a user cannot simply invoke the appropriate CoreFoundation function on the RunLoop's inner (CFRunLoop) object. In order to not expose any new CoreFoundation APIs, we need to expose the functionality from the Swift layer. This is motivated by the desire to minimise the divergence from the reference implementation of CoreFoundation. The Swift API surface is meant to be near identical to the Objective-C implementation. An option would be to expose a SPI for users to control the behvaiour of the `RunLoop` with regards to the Windows message loop. One caveat that exists is that CoreFoundation seems to exempt the common modes from being able to participate in the windows message loop. Fortunately, the main run loop, which is tied to the main thread, is configured to run in the default mode which may participate in the OS message loop. Additionally, the Windows UI system expects to perform the operations on the main thread, which gives us a natural point to alter the behaviour of `RunLoop`. There are two instances of `CFRunLoopGetMain`, one which provides the storage for the main runloop, and one which is the accessor for the main runloop. Because the accessor will perform additional reference counting and bridging behavioural changes, use the `CFRunLoop` storage of the `_mainRunLoop` to acquire the main run loop. Co-authored-by: Darin Fisher <darinf@gmail.com>
compnerd
force-pushed
the
driving-everyone-loopy
branch
from
9eaaba7 to
aea8b22
Compare
|
Please test with following PRs: @swift-ci please test Windows platform |
|
@swift-ci please test Linux platform |
parkera
approved these changes
Jun 26, 2023
|
First of all, thank you for taking the time to fix this. For clarification, this happens trying to build without checking this PR. |
|
@ItaiBear its difficult to say without seeing the full output. I suspect that there might be some mixups - note that currently if you have Swift installed, you will not be able to build the full toolchain. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When processing events on the main runloop, we should unmask the Windows message pump events. If we do not unmask these events, the main RunLoop is unable to process the UI events and the user has no mechanism for integrating the Windows message pump events into the run loop.
This is a slightly restrictive compromise to enable the use of RunLoop on Windows for pumping a UI application. Because CoreFoundation is not a supported API surface a user cannot simply invoke the appropriate CoreFoundation function on the RunLoop's inner (CFRunLoop) object. In order to not expose any new CoreFoundation APIs, we need to expose the functionality from the Swift layer. This is motivated by the desire to minimise the divergence from the reference implementation of CoreFoundation.
The Swift API surface is meant to be near identical to the Objective-C implementation. An option would be to expose a SPI for users to control the behvaiour of the
RunLoopwith regards to the Windows message loop. One caveat that exists is that CoreFoundation seems to exempt the common modes from being able to participate in the windows message loop. Fortunately, the main run loop, which is tied to the main thread, is configured to run in the default mode which may participate in the OS message loop. Additionally, the Windows UI system expects to perform the operations on the main thread, which gives us a natural point to alter the behaviour ofRunLoop.There are two instances of
CFRunLoopGetMain, one which provides the storage for the main runloop, and one which is the accessor for the main runloop. Because the accessor will perform additional reference counting and bridging behavioural changes, use theCFRunLoopstorage of the_mainRunLoopto acquire the main run loop.