Skip to content
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

Concurrency: support draining the main queue in single threaded mode #35584

Merged
merged 1 commit into from
Jan 26, 2021

Conversation

compnerd
Copy link
Member

When built in single threaded mode, the runtime does not use dispatch to
queue the tasks. As a result, pumping the dispatch main queue will
simply wait indefinitely. In the single threaded mode, simply halt
execution and drain all pending tasks before returning. This allows
forward progress in the single threaded mode.

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

Resolves SR-NNNN.

When built in single threaded mode, the runtime does not use dispatch to
queue the tasks.  As a result, pumping the dispatch main queue will
simply wait indefinitely.  In the single threaded mode, simply halt
execution and drain all pending tasks before returning.  This allows
forward progress in the single threaded mode.
@compnerd
Copy link
Member Author

@etcwilde not sure if this is the best way to handle this; perhaps in single-threaded mode, we should never arrive at this point and we should be changing the Swift path itself?

@compnerd
Copy link
Member Author

@swift-ci please test

Copy link
Contributor

@etcwilde etcwilde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@etcwilde not sure if this is the best way to handle this; perhaps in single-threaded mode, we should never arrive at this point and we should be changing the Swift path itself?

I think this looks fine. It looks pretty much the same as how runAsyncAndBlock is implemented for single-threaded mode.

I think we definitely want to allow concurrent code in single-threaded mode. Not quite following what you mean by "changing the Swift path itself", unless you mean that the maybe we have a different endpoint to call for running the async-main? Maybe? I would kind of like to keep logic for "draining the main queue and never returning" kept in one place, but if we get too many preprocessor macros going on here, it might make sense.

@compnerd
Copy link
Member Author

Yeah, I meant having a different end point coming in from the Swift side. Sounds like this approach is reasonable enough for now, so lets go with that.

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 4f740a4

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 4f740a4

@compnerd
Copy link
Member Author

@swift-ci please smoke test Linux 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 - 4f740a4

@compnerd
Copy link
Member Author

@swift-ci please smoke test macOS platform

@compnerd compnerd merged commit 62f9050 into swiftlang:main Jan 26, 2021
@compnerd compnerd deleted the single-threaded-drain branch January 26, 2021 04:06
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.

3 participants