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 <damienrad...@gmail.com>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 <ke...@sb.org> 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 <damienrad...@gmail.com> >> 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 <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
