Skip to content

Conversation

@gottesmm
Copy link
Member

We can perform more aggressive optimizer optimizations with nonisolated(nonsending) than #isolation. So use that instead to get some easy perf wins.

We can perform more aggressive optimizer optimizations with nonisolated(nonsending) than #isolation. So use that instead to get some easy perf wins.
}

@inlinable
mutatingfunc next(
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we can change this one since this is a protocol requirement of AsyncSequence unless nonisolated(nonsending) methods are capable of fulfilling isolated protocol requirement


@inlinable
func suspendNext(isolation: isolated (anyActor)?= #isolation)asyncthrows->Element?{
nonisolated(nonsending)func suspendNext()asyncthrows->Element?{
Copy link
Contributor

Choose a reason for hiding this comment

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

in my recent testing, it seems nonisolated(nonsending) does not grant the ability to actually procure a reference to the isolated parameter in a way that allows isolating closures in the same manner that capturing an explicit isolated parameter does. i suppose in this case it doesn't matter since the parameter isn't being captured by the body closures, but that does make me wonder if those closures are actually not being isolated in the intended manner currently.

Copy link
Member

Choose a reason for hiding this comment

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

Could you briefly expand what closures you are worried are not isolated in particular?

Copy link
Contributor

@jamieQjamieQDec 18, 2025

Choose a reason for hiding this comment

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

so, the concern would be that even though the method inherits isolation by default (in the original formulation), the isolated parameter is unused within the body closures. this is true in the prior version with an isolated parameter, and seems to also be true even after converting to implicit caller isolation inheritance. this means the actual 'work' invoked by the with* runtime methods isn't isolated, so IIUC it's going to require an executor hop if the caller is actor-isolated. this can be seen in this sort of example: https://swift.godbolt.org/z/GP4dPhfKv.

Copy link
Member

@FranzBuschFranzBuschDec 18, 2025

Choose a reason for hiding this comment

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

Ah so you are talking about the withTaskCancellationHandler and withCheckedContinuation handler. Both of them have open PRs to address these issues swiftlang/swift#85191 & swiftlang/swift#85518

Edit: I see that you left a comment on the latter PR. The hop should be eliminated and I think @gottesmm is looking into that.

Sign up for freeto 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

@gottesmm@jamieQ@FranzBusch