So I managed to implement a solution without needing a child task, using Kevin's initial idea of a struct with private fields and public getters. The idea had occurred to me but I wasn't sure exactly how to implement it; needless to say, I think I was overcomplicating things.
Thanks for the help, Kevin. On Fri, Feb 14, 2014 at 4:18 PM, Damien Radtke <[email protected]>wrote: > Ah, I think the problem is that I'm trying to create a new task within a > loop over an iterator, so each value is an &-ptr and is therefore causing > it to fail... > > > On Fri, Feb 14, 2014 at 4:12 PM, Damien Radtke <[email protected]>wrote: > >> 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
