The function pointer is indeed a function pointer and all of the strings and vectors are ~, but the vector type is &'static. They're meant to hold references to card definitions, which is more efficient than passing around the cards themselves. I tried modifying the vectors to hold ~-strings instead, but it still didn't work.
Looks like I'll need to do more research on Send. On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard <[email protected]> wrote: > 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 >> >> > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
