Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send?
On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard <ke...@sb.org> wrote: > What if the state's fields are private, and in a different module than the > players, but exposes getters to query the state? Then the players can't > modify it, but if the component that processes the actions has visibility > into the state's fields, it can modify them just fine. > > -Kevin > > On Feb 14, 2014, at 12:22 PM, Damien Radtke <damienrad...@gmail.com> > wrote: > > > I'm trying to write what is essentially a card game simulator in Rust, > but I'm running into a bit of a roadblock with Rust's memory management. > The gist of what I want to accomplish is: > > > > 1. In the program's main loop, iterate over several "players" and call > their "play" method in turn. > > 2. Each "play" method should be able to send requests back to the parent > in order to take certain actions, who will validate that the action is > possible and update the player's state accordingly. > > > > The problem I'm running into is that, in order to let a player "play" > and have the game validate actions for them, I would need to run each > player in their own task, (I considered implementing it as each function > call indicating a request for action [e.g. by returning Some(action), or > None when finished] and calling it repeatedly until none are taken, but > this makes the implementation for each player needlessly complex) but this > makes for some tricky situations. > > > > My current implementation uses a DuplexStream to communicate back and > forth, the child sending requests to the parent and the parent sending > responses, but then I run into the issue of how to inform the child of > their current state, but don't let them modify it outside of sending action > requests. > > > > Ideally I'd like to be able to create an (unsafe) immutable pointer to > the state held by the parent as mutable, but that gives me a "values differ > in mutability" error. Other approaches so far have failed as well; Arcs > don't work because I need to have one-sided mutability; standard borrowed > pointers don't work because the child and parent need to access it at the > same time (though only the parent should be able to modify it, ensuring its > safety); even copying the state doesn't work because the child then needs > to update its local state with a new copy sent by the parent, which is also > prone to mutability-related errors. > > > > Any tips on how to accomplish something like this? > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
