Alternative to pattern which would need double mutable borrow?

[jerome-trc]

I'm trying to emulate a pattern I've seen in a few different game engines, all in C++. The premise is that something happens during a mutating operation in Rust code that triggers a mutating callback in Lua. The corresponding Rust code, simplified, would look like this:

let lua = Lua::new();
let mutating_lua_func = lua.create_function(|_, _| {
  // _Absolutely must_ be able to modify anything in `game_state`
  Ok(())
});
lua.globals().set("mutating_func", mutating_lua_func);

for thing in game_state.characters() {
  let need_script_call = thing.mutate(); // Rust function

  if need_script_call {
    lua.globals().get("mutating_func").call();
  }
}

I can't see any way of allowing this without borrowing game_state mutably once in the for loop and then again in the callback. If I use app data, the cell borrow will panic in the callback. Same with userdata wrapping an Rc. Callbacks holding Arc<Mutex<>> will deadlock. Non-static userdata loses the underlying type.

Is this just something that Rust will not allow? Is there an entirely other way I could be structuring this to fix all of this? I know it's a reasonable use case; if I want, for example, enemy damage code to happen in Rust while a script responds to that damage by calling into random number generators, modifying level geometry, modifying the rest of the ECS, et cetera, I at least need something similar.

[khvzak]

What is inside game_state?
Generally you can add interior mutability (via RefCell for example) to parts that need to be mutated.

Or maybe you can iterate over indicies of elements and then mutably borrow game_state for each index independently.

for i in 0..n {
    let mut thing = &mut game_state.characters()[i];
    let need_script_call = thing.mutate();
    drop(thing);
    if need_script_call {
        lua.globals().get("mutating_func").call();
    }   
}

If the code runs in a single thread also ReentrantMutex can be used to lock the mutex recursively.

[jerome-trc]

I think I figured out what I needed:

• Initialize closures for script's API in advance using Arc<Mutex<>>.
• Lock a mutex around all game state.
• Collect all indices for something that needs to be iterator over into a pre-reserved Vec.
• Iterate over those indices. If Lua needs to run a script for something, drop the mutex guard.
• Lua-owned closure acquires mutex guard, runs some Rust code, drops the guard.
• Overlying loop re-acquires the guard and continues.
  It's not ideal performance-wise - I was hoping to be able to avoid running a lock for every native call in what could potentially be thousands of native scripts, and I'd prefer not to have to do so much iterator-collecting - but parking_lot's primitives are pretty quick, things could be worse, and now I have a solution.

I'm not sure I would have thought of this if I wasn't considering the answer you gave. Thanks for your time and consideration.