Skip to content

[6.2][Concurrency] Improve in order synchronous enqueue of startSynchronously #80852

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

Conversation

ktoso
Copy link
Contributor

@ktoso ktoso commented Apr 16, 2025

Description:
Previously there was still a sneaky hop which caused ordering issues. This introduced a specific test startSynchronously_order which checks that the task enqueues indeed are "immediate" and cleans up how we handle this.

This also prepares for the being discussed in SE review direction of this API that it SHOULD be ALLOWED to actually hop and NOT be synchronous at all IF the isolation is specified on the closure and is DIFFERENT than the callers dynamic isolation.

This effectively implements "synchronously run right now if dynamically on the exact isolation as requested by the closure; otherwise enqueue the task as usual".

Scope/Impact: Specifically fixes run order of the "synchronously start task" when nonisolated target closure
Risk: Low, fixes semantics of new API in 6.2
Testing: New test to verify the enqueue order
Reviewed by: @drexin

Original PR: #80821
Radar: rdar://149284186

ktoso added 2 commits April 16, 2025 19:12
Previously there was still a sneaky hop which caused ordering issues.
This introduced a specific test startSynchronously_order which checks
that the task enqueues indeed are "immediate" and cleans up how we
handle this.

This also prepares for the being discussed in SE review direction of
this API that it SHOULD be ALLOWED to actually hop and NOT be
synchronous at all IF the isolation is specified on the closure and is
DIFFERENT than the callers dynamic isolation.

This effectively implements "synchronously run right now if dynamically
on the exact isolation as requested by the closure; otherwise enqueue
the task as usual".

resolves rdar://149284186
cc @drexin
@ktoso
Copy link
Contributor Author

ktoso commented Apr 16, 2025

@swift-ci please test

@ktoso ktoso added the concurrency Feature: umbrella label for concurrency language features label Apr 17, 2025
@ktoso
Copy link
Contributor Author

ktoso commented Apr 18, 2025

This will get more changes later

@ktoso ktoso closed this May 12, 2025
@ktoso ktoso reopened this May 12, 2025
@ktoso
Copy link
Contributor Author

ktoso commented May 28, 2025

I dont think we need this anymore, given other fixes done to Task.immediate

@ktoso ktoso closed this May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
concurrency Feature: umbrella label for concurrency language features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant