You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, all messages going into an actor must have a static lifetime. While this can be managed by cloning, it would be nice to provide an API similar to that of thread::scope. This is conceptually very easy, but there are a lot of cornercases, and expressing it will be difficult.
Simply managing the lifetimes of this interprocess communication will require a fair amount of consideration (and a manual Drop implementation). But beyond the Rust-based issues, rendering this pattern into the current semantics of troupe will also be difficult. How do you open a scope? How does the scheduler/actor handle this? Does this require a second actor state? Maybe a trait for the messages?
The text was updated successfully, but these errors were encountered:
Currently, all messages going into an actor must have a static lifetime. While this can be managed by cloning, it would be nice to provide an API similar to that of
thread::scope
. This is conceptually very easy, but there are a lot of cornercases, and expressing it will be difficult.Simply managing the lifetimes of this interprocess communication will require a fair amount of consideration (and a manual
Drop
implementation). But beyond the Rust-based issues, rendering this pattern into the current semantics oftroupe
will also be difficult. How do you open a scope? How does the scheduler/actor handle this? Does this require a second actor state? Maybe a trait for the messages?The text was updated successfully, but these errors were encountered: