Hello,
> On 31. Aug 2017, at 20:35, Joe Groff via swift-evolution
> <[email protected]> wrote:
>
> # `onResume` hooks
>
> Relying on coroutine context alone still leaves responsibility wholly on
> suspending APIs to pay attention to the coroutine context and schedule the
> continuation correctly. You'd still have the expression problem when
> coroutine-spawning APIs from one framework interact with suspending APIs from
> another framework that doesn't understand the spawning framework's desired
> scheduling policy. We could provide some defense against this by letting the
> coroutine control its own resumption with an "onResume" hook, which would run
> when a suspended continuation is invoked instead of immediately resuming the
> coroutine. That would let the coroutine-aware dispatch_async example from
> above do something like this, to ensure the continuation always ends up back
> on the correct queue:
I do feel the “correct” scheduling should be done by the actual scheduler /
run-loop system, so we’re not paying the context switch cost twice. Of course
this means that the run-time / OS needs enough information to do this correctly.
To be honest, the enqueuing of messages to actors seems quite straight-forward,
but I’m having trouble envisioning the draining / processing of the messages.
Daniel.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
