I create a continuation to allow users to wait for network data captured by an actor and capture its resume in a stored closure. When that capture is complete, I call the enqueued closures to trigger the continuations. Strictly calling the closure within an actor method works fine. Wrapping the closure call in an unstructured task causes a hang and the waiter is never notified. However, simply adding a print statement at the end of the actor method allows it to work. My test iOS project is attached.
The text was updated successfully, but these errors were encountered:
This seems to have regressed further in beta 2. Now none of my awaited work seems to complete unless I put a `print` statement in the `request` method before returning the `DataRequest` value. The `print` at the end of `didComplete` is still necessary if the continuations are resumed within an unstructured task.
will await pause
will await go
in withCheckedContinuation operation
completing withCheckedOperation closure
So it seems that it never actually enters the `go()` function. When it works it seems that the withCheckedContinuationClosure is completed before go is awaited.
This may actually be more related to the issue in release notes "Swift tasks won't have their priority escalated in response to awaiting on their handles. (76127623)" although I don't think there needs to be any escalation. The issue does seem dependent on the different priorities and other test cases seem to now be working. As before with my test cases this doesn't fail every time but does fail a few times in every hundred.
Hmm, this should've been fixed in beta 5. The change that was made was that all priorities get "squashed" to the unspecified level (because the smarter scheduling that took priorities into account wasn't working) so high vs low priority shouldn't matter.
I'll double-check on whether the change landed in time for beta 5 or not.