Depends. If the string or the vectors are & instead of ~, that would do it. Also, if the element type of the vector does not fulfill Send. Oh, and the function pointer is a function pointer, not a closure, right?
-Kevin On Feb 14, 2014, at 12:59 PM, Damien Radtke <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > https://mail.mozilla.org/listinfo/rust-dev > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
