Skip to content

Concurrency: avoid CFRunLoopRun on non-Darwin #35585

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 29, 2021

Conversation

compnerd
Copy link
Member

The CoreFoundation implementation on non-Darwin platforms included in
Foundation is not meant to be used as a general purpose CoreFoundation
implementation. Since non-Darwin targets do not default to providing a
CoreFoundation implementation, we should generally assume that the
symbol is not present. This changes the non-Darwin paths to always use
dispatch_main rather than CFRunLoopRun.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

The CoreFoundation implementation on non-Darwin platforms included in
Foundation is not meant to be used as a general purpose CoreFoundation
implementation.  Since non-Darwin targets do not default to providing a
CoreFoundation implementation, we should generally assume that the
symbol is not present.  This changes the non-Darwin paths to always use
`dispatch_main` rather than `CFRunLoopRun`.
@compnerd
Copy link
Member Author

CC: @etcwilde

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

CC: @millenomi

@millenomi
Copy link
Contributor

cc @phausler — will this compromise anything because of the different entry point?

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 472e842

@phausler
Copy link
Contributor

This seems reasonable to me, there are some sneaky side effects here to consider.

  1. This means that all usages of this will incur a runloop
  2. not doing this will cause strangeness when it comes to some APIs like NSDistributedNotificationCenter etc. just using dispatch_main ends up causing problems when daemons use certain APIs that schedule things onto the main runloop instead of dispatching async to the main queue (because of historical reasons they need to be maintained as such)
  3. There are certain characteristics like scheduled execution ala performSelector etc that may have behavioral differences but hopefully actors and async/await will obviate the need for those

I would like to see a unified approach for all platforms but sadly I don't think we can avoid calling the CF API.

@compnerd
Copy link
Member Author

@swift-ci please smoke test macOS platform

@compnerd
Copy link
Member Author

@swift-ci please test macOS platform

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 472e842

@compnerd
Copy link
Member Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 472e842

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd compnerd merged commit 3cf257f into swiftlang:main Jan 29, 2021
@compnerd compnerd deleted the runless branch January 29, 2021 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants