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
The specific scenario I have in mind is for failure recovery of actors. Imagine you have some type that represents the actor state, and it contains a Port.
struct Actor {
port: Port<ActorMsg>;
... local state ...
}
As an actor, this port is your lifeline to the rest of the world. So the actor is sitting in its task processing events and one of them fails. Most actor systems have one or more recovery and restart strategies. Some of them may preserve the local state and resume processing at the next message, some may assume the state has been corrupted and resume processing messages from scratch.
In Rust I have decided that implementing actor recovery is best done by shipping the Port off to a fresh task, so a scenario where you wanted to recover while wiping out the local state may look like:
impl Actor: Drop {
fn finalize(&mut self) {
if failing() {
let mut saved_port = ... some stand in value ...
self.port <-> saved_port;
spawn {
Actor::resume(port);
}
}
}
}
I'd propose closing this as WONTFIX in favour of #4330 -- while that bug requires us to come up with an extra rule to prevent multiple destruction (eg. "only a destructuring move is allowed in dtor") it also means we don't have to fill destroyable objects with options and permit that many more invalid runtime states.
Activity
catamorphism commentedon Jan 17, 2013
Maybe I'm being dense, but why would you want to mutate
selfwhenselfis about to be freed? Is there any way that such changes would be observable?brson commentedon Jan 17, 2013
That's a good question!
The specific scenario I have in mind is for failure recovery of actors. Imagine you have some type that represents the actor state, and it contains a
Port.As an actor, this port is your lifeline to the rest of the world. So the actor is sitting in its task processing events and one of them fails. Most actor systems have one or more recovery and restart strategies. Some of them may preserve the local state and resume processing at the next message, some may assume the state has been corrupted and resume processing messages from scratch.
In Rust I have decided that implementing actor recovery is best done by shipping the
Portoff to a fresh task, so a scenario where you wanted to recover while wiping out the local state may look like:catamorphism commentedon Jan 17, 2013
Thanks for the clear explanation!
thestinger commentedon Jan 18, 2013
Related: #4330 (taking self by-value in finalize), which would also allow moving out of self
graydon commentedon May 29, 2013
I'd propose closing this as WONTFIX in favour of #4330 -- while that bug requires us to come up with an extra rule to prevent multiple destruction (eg. "only a destructuring move is allowed in dtor") it also means we don't have to fill destroyable objects with options and permit that many more invalid runtime states.
@brson are you ok with that?
brson commentedon May 29, 2013
@graydon yes
Merge rust-lang#4514