You can’t move out of a MutexGuard is the issue
#Tokio Sync Mutex type err
summer steppe
dry wren
Ah gotcha
summer steppe
Would it work for shadow_update_state to take groups as an &mut instead?
dry wren
yeah probably
i just dont want to update the original var groups
its meant to just clone it
or update it then revert it at the end of the fn
summer steppe
Ah, then just do groups.clone() at the call site instead?
Yeah, whatever works better for your code
summer steppe
If yoy clone at global_state, because of the way Arc works, it’ll just create a new Arc pointing to the same data
summer steppe
Instead, you want to lock global_state, and call clone on the MutexGuard; MutexGuard doesn’t implement Clone, but it does implement Deref;
So basically since MutexGuard<T> implements Deref<Target=T>, the compiler can treat &MutexGuard<T> as &T, so you can call .clone() on the MutexGuard and it’ll pop off a clone of BTreeMap
dry wren
oops sorry same ss
summer steppe
Well, that particular error is because you used global_state inside the async move block in the tokio::spawn earlier on; that is a case where you do want to clone the arc, and then use the cloned arc inside the async move
Async move means that anything that the future captures from outside the async move will actually be moved in, regardless of whether you move it inside that block or not
dry wren
Async move means that anything that the future captures from outside the async m...
ah okay
my goal with that one was to update the global_state from the thread
then use that updated state with this loop
summer steppe
Ah. Well, it would indeed work like that, although it’s possible that the calls won’t be interleaved nicely (not sure if tokio mutexes are fair or not)
dry wren
Ah. Well, it would indeed work like that, although it’s possible that the calls ...
is it possible i can move it back ?
summer steppe
Move what back?
dry wren
then i can clone the arc again in the other loop?
summer steppe
Don’t need to clone it a second time, you can use the original instance for the other loop as long as you don’t move it somewhere else
summer steppe
Yeah basically
dry wren
wouldnt cloning clone just create the same reference
summer steppe
Almost there; add a .clone() after the deref
dry wren
Almost there; add a .clone() after the deref
still got the same error D:
basically, im changing a few variables in groups then using that, then dropping it later
or at least thats the intention
why does clone create a reference
summer steppe
I’m doing this and it seems to be working as expected
dry wren
but no deref
summer steppe
Usually, the compiler does that automatically; i also just tried with g.deref().clone() and it still works—have you run cargo check? Might just be the ide not recognizing the change
dry wren
but
i think clone would just adjust g_state which would change the original global_state
summer steppe
Yep
summer steppe
Try (&g_state).clone()?
Wait nvm dont try that
Yeah, idk what’s up with that; g_state.deref().clone() should work
dry wren
Yeah, idk what’s up with that; g_state.deref().clone() should work
that just gives me a reference
did you try with deref?
summer steppe
I don’t think you are; do you think you could try with Clone::clone(<MutexGuard<_> as Deref>::deref(&g_state)) ?
summer steppe
Well, it’s fairly late over here for me and i need to head off—try asking #rust-discussions-3 ?
dry wren
Okay, thanks fren ❤️
summer steppe
Yeah np, sorry I couldn’t be more help
summer steppe
True, it do be like that sometimes
summer steppe
Just spent the last ~three hours trying to figure out some weird async stuff only to find that all i needed was to wrap a type in an option ,_,