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

Actor coroutines #4

Open
uazu opened this issue Dec 2, 2020 · 0 comments
Open

Actor coroutines #4

uazu opened this issue Dec 2, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@uazu
Copy link
Owner

uazu commented Dec 2, 2020

An actor coroutine would run detached from the actor, but receives the actor &mut Self and cx: &mut Cx<'_, Self> references whenever it is resumed, i.e. the code runs within a normal actor context. So the idea is that actor code within a coroutine could do anything that an actor method could do, but in a sequential style. This also allows calls to other actors to happen apparently synchronously in the code (although it is still all asynchronous underneath). So a call to another actor would return the same value that a Ret handler receives right now, but directly in the code. (? could perhaps be used to handle failures).

Actor coroutines would be behind an Rc (or similar), and would be held in memory by the internal Ret handler -- or whatever suspended the coroutine and will resume it later. So they would get dropped if nothing is ever going to resume them again (i.e. actor coroutines would need to be ready to be dropped without completing). There could be two types of coroutines, one which terminates the actor when it completes, and another which just runs to completion without affecting the actor lifetime. It would be possible to run several actor coroutines at the same time, each held in memory by whatever is going to resume it. Cleanup is straightforward -- if whatever would resume the coroutine is dropped, the coroutine is also dropped. If the actor is terminated, then resuming the coroutine would just do nothing (similarly to how outstanding calls to an actor are dropped if it has terminated), and any Ret instances would send back None.

Actor coroutines would also enable convenient offloading of processing to background threads, because that could be represented as a wrapped block of code which effectively yields the coroutine until the background processing is complete. The apparently-synchronous nature of the coroutine code would make this clearer and more convenient in the source.

This feature is blocked on a Rust generator feature that would allow borrows to be passed into the coroutine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant